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fREFACE 


Corrputer  performance  evaluation  (CPE)  is  primarily  a  matter 
of  economics.  Wiereas  some  evaluate  a  modeling  methodology  in 
theoretical  terms,  the  CPE  analyst  must  ask  questions  of  more  direct 
application:  "Does  it  work?";  "How  much  will  it  cost?"  CPE  tends 
to  be  a  pragmatic  discipline  aimed  at  having  a  direct  impact  upon 
the  Automatic  Data  Processing  (ADP)  dollar's  efficiency. 

The  relationship  between  ADP  and  CPE  costs  has  fostered 
growing  oommitment  in  government  and  industry  to  the  development  of 
effective  CPE  tools.  This  commitment  has  resulted  in  CPE's  trans¬ 
formation  into  a  multimillion  dollar  industry  and  an  inportant 
conputer  science  research  discipline.  Not  many  years  ago,  performance 
measurement  and  analysis  was  a  "seat  of  the  pants"  endeavor  to  all 
but  a  small  coterie  of  experts.  Today,  sophisticated  packaged  tools 
exist  which  allow  the  trained  technician  to  easily  and  accurately 
model  and  evaluate  many  aspects  of  a  computer  system's  performance. 

Despite  the  economic  significance  and  considerable  progress 
which  the  performance  evaluation  community  has  enjoyed  during  recent 
years,  CPE  researchers  have  still  had  difficulty  responding  to  the 
challenges  posed  by  new  system  architectures  and  operating  philos¬ 
ophies:  CPE  tools  are  needed  which  can  be  used  to  develop  accurate 
deterministic  models  of  parallel  systems  at  a  snail  cost  relative  to 
the  system  cost.  Current  CPE  tools  do  not  adequately  meet  these 
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challenges.  For  example,  as  this  Thesis  points  out,  the  queueing 
network  model  is  a  user-oriented,  inexpensive  modeling  tool.  Yet, 
the  basic  assunptions  of  the  model  make  it  an  inadequate  tool  for 
studying  many  deterministic  parallel  systems.  Vhen  these  inadequacies 
become  important  factors  in  a  study,  the  CPE  analyst  must  either 
accept  an  approximate  solution  or  use  other  more  expensive  and  more 
cumbersome  modeling  methods,  such  as  discrete  simulation. 

Because  of  the  importance  of  parallel  systems  within  the 
ADP  user  community,  there  is  a  strong  need  for  a  cost-effective, 
data-driven  performance  modeling  methodology  vhich  can  faithfully 
represent  deterministic  behavior,  process  blocking,  and  the  holding 
of  multiple  resources  by  a  single  process.  At  least  one  study 
[Browne,  et.  al.,  1973]  has  shown  that  currently  available  tools  are 
inadequate  due  to  their  expense,  difficulty  of  use,  or  inherent 
modeling  limitations;  in  some  cases  these  limitations  are  significant 
constraints. 

The  objective  of  this  Thesis  is  to  introduce  a  modeling 
methodology  Which  meets  the  needs  described  above.  Wiile  it  would 
be  naive,  if  not  presunptuous ,  to  imply  an  ultimate  solution,  the 
methodology  is  demonstrated  to  be  useful  in  analyzing  the  perform¬ 
ance  of  a  sophisticated  disk  subsystem  that  can  only  be  approx¬ 
imated  by  queueing  networks.  The  capabilities  of  the  model 
demonstrated  by  this  example  problem  seem  to  indicate  that  the 
Time-Extended  Petri  Net  (TETO)  offers  a  fresh  and  useful  tool  for 


cost-effective  CPE 
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CHAPTER  I 


INTRODUCTION 

This  Thesis  introduces  the  Time-Extended  Petri  Net  (TEPN) 
as  a  basis  for  computer  system  performance  modeling,  and  demon¬ 
strates  the  TEPN's  usefulness  in  modeling  a  specific  computer 
system  problem.  We  suggest  from  preliminary  modeling  results  that 
the  TEPN  model  is  extendable  to  more  general  application  in  the 
performance  evaluation  of  both  system  and  algorithm  architectures. 

The  TEFN  model  resulted  from  a  project  whose  goal  was  to 
define  and  implement  a  modeling  system  which  would: 

(1)  represent  the  time-resolved  behavior  of  a  set  of 
deterministic  interacting  parallel  processes; 

(2)  represent  the  holding  of  multiple  resources;  and, 

(3)  allow  specification  of  models  as  data  structures 
rather  than  as  programs.1 

When  properly  implemented ,  this  system  combines  much  of 
the  power  and  flexibility  of  programmed  simulation  models  with  the 
ease  of  use  of  queueing  models,  resulting  in  a  powerful  and  cost- 
effective  modeling  tool. 

1  Queueing  models  and  System  Program  Graphs  are  exanples  of  models 
vjhich  are  specified  as  data  structures  which  may  then  be  analyzed 
by  a  pre-ccrpiled  program  which  merely  "executes"  the  structure; 
discrete  language  simulation  models  are  specified  by  a  computer 
program  and  the  model  itself  must  be  compiled  and  validated  as  a 
ocrputer  program  as  well  as  a  model. 
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The  TEPN  is  constructed  from  the  general  Petri  net  by 

(1)  associating  type  and  information  content  with  tokens; 

(2)  associating  with  each  place  a  set  of  functions  and 
state  information  derived  from  the  tokens  at  that  place;  and, 

(3)  associating  input  and  output  templates  with  each 
transition  to  govern  the  firing  of  a  transition  and  flow  of  infor¬ 
mation  through  the  network. 

The  deterministic  properties  of  the  TEEN  structure  remain 
unchanged  from  those  of  the  general  Petri  net,  if  suitable 
restrictions  on  the  information  content  of  tokens  and  the  range  of 
the  functions  are  made.  This  combination  of  Petri  net  properties 
and  the  above  extensions  results  in  a  model  whose  power  of  repre¬ 
sentation  and  mode  of  definition  meet  the  goals  stipulated  above. 

Thesis  Organization 

Other  than  the  work  of  Noe  and  Nutt  [Noe  and  Nutt,  1972 
and  1973],  the  author  knows  of  no  major  documented  research  into 
using  the  Petri  net  as  the  basis  for  a  CPE  tool.  However,  the 
reader  will  be  helped  by  a  familiarity  with  the  relationship  of 
the  TEPN  to  other  major  CPE  modeling  methods,  and  this  background 
information  is  presented  in  Chapter  II. 

Chapter  III  supports  the  TEEN  conceptual  definition  by 
presenting  seme  basic  definitions  of  the  Petri  net,  upon  which  the 
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TEIN  model  is  based  and  briefly  describes  other  major  research 
concerned  with  adapting  the  Petri  net  as  a  CPE  tool. 

Chapters  IV  and  V  define  and  describe  the  basic  concepts 
and  the  impl ementa tion  of  the  TEFN  model,  thereby  presenting  the 
bulk  of  the  "new"  material  contained  in  this  Thesis.  The  reader 
already  familiar  with  Petri  nets  and  other  computer  performance 
evaluation  (CPE)  modeling  methods  may  want  to  begin  this  Thesis 
with  these  chapters. 

Chapter  VI  illustrates  the  usefulness  of  the  TEPN  system 
in  analyzing  the  performance  of  a  ccmpl ex  disk  subsystem. 

Chapter  VII  concludes  the  Thesis  with  observation  con¬ 
cerning  the  TEPN's  future  as  a  CPE  tool  and  suggests  some  directions 
for  future  research. 


CHAPTER  II 


SURVEY  OF  CPE  MODELING  TECHNIQUES 


This  chapter  suverys  the  three  major  CPE  modeling  techniques 
in  documented  use  by  the  CPE  camunity.  We  discuss  first  the  discrete 
simulation  methodology,  then  analytic  queueing  network  models,  and 
finally  trace-driven  models.  Although  none  of  these  techniques  employ 
the  Petri  net,  their  understanding  is  fundamental  to  understanding 
the  objective  behind  the  TEFtt  network. 


Discrete  Simulation  Modeling 

Discrete  computer  system  simulation  involves  the  description 

of  a  computer  system  by  a  computer  probram  and  the  simulation  of  the 

interactions  within  that  system  as  they  occur  ever  a  discrete  time 

interval.  The  level  of  detail  of  the  representation  within  a  discrete 

simulation  model  may  vary  from  simulated  interactions  to  a  one-to-one 

mapping  of  actual  system  interactions  depending  \jpon  the  computer 
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language  used  and  the  problem's  requirements. 

Most  discrete  simulation  languages  were  developed  in  the 

1950' s  and  1960's  as  tools  to  study  oonplex  processes  and  system 

2  '  ~ 

The  kind  of  problem  generally  determines  the  required  and/or 

desired  level  of  model  detail,  as  well  as  deciding  whether  the 
model  should  be  deterministic  (i.e.,  no  random  variability)  or 
nondeterministic .  For  exanple,  an  analysis  of  the  performance  of 
a  new  logic  circuit  would  normally  require  a  very  detailed  model; 
a  logic-circuit  level  model  of  a  large  multiprocessor  system 
would  be  neither  feasible  nor  useful.  Similarly,  the  logic  circuit 
analysis  would  probably  require  a  deterministic  model,  whereas 
random  variability  is  an  important  part  of  most  large  system  models. 
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design.  One  of  the  earliest  and  best-known  simulation  languages  is 
IBM's  GPSS  [Efron  and  Gorden,  1969].  This  language  is  problem  and 
user  centered;  it  has  features  which  allow  the  user  to  describe  the 
flow  of  work  through  the  processes  which  are  to  be  simulated  in  a 
flowchart-like  format.  While  not  used  extensively  for  CPE,  the  GPSS 
language  is  still  very  popular  in  many  other  areas  of  computer-based 
simulation.3 

The  most  significant  special-purpose  simulation  language 
for  CPE  is  the  Extendable  Computer  System  Simulator  (ECSS)  [Nielson, 
1969] .  Developed  by  RAND  Corporation  to  add  in  studies  of  computer 
hardware  and  software  systems,  ECSS  is  a  superset  of  the  SUBSCRIPT  II 
[Kiviat,  et.  al_. ,  1969]  programming  language  with  several  embedded 
features  uniquely  required  when  modeling  computer  systems.  ECSS  has 
been  and  continues  to  be  applied  to  large  CPE  problems,  particularly 
within  the  Federal  Government. 

Another  type  of  specialized  discrete  simulation  tool  is 
the  packaged  simulator,  of  which  the  Computer  Assisted  System  Eval¬ 
uator  (CASE)  [CASE  Manual,  1962]  is  the  most  notable  example.  CASE 
is  a  prefabricated  model  of  an  arbitrary  computer  system  defined 
at  run  time  by  the  user.  The  input  to  the  package  consists  of  a 
configuration  description  and  a  workload  description,  while  the 

3 — — - - - - — — - 

CPE  uses  of  GPSS  and  most  other  simulation  languages  (to  simulate 
computer  system  performance)  comprise  a  relatively  small  percentage 
of  all  simulation  applications,  as  evidenced  by  the  papers  contained 
in  the  proceedings  of  the  various  simulation  conferences  (proceedings 
of  major  simulation  conferences  are  available  from  the  Association 
for  Computing  Machinery  (AO!)  and  the  Institute  of  Electronics  and 
Electrical  Engineers  (IEEE)  ). 


output  is  a  series  of  reports  on  the  performance  of  each  part  of  the 
system  as  a  whole.  The  package  contains  intrinsic  information 
concerning  the  performance  characteristics  of  each  piece  of  "legal" 
hardware,  indexed  by  make,  model  number,  and  vendor.  To  cover  the 
software  inpacts  upon  system  performance,  CASE  not  only  contains 
standard  factors  relevant  to  the  major  operating  systems  it 
"supports,"  but  also  allows  the  user  to  specify  many  parameters 
which  are  normally  part  of  the  operating  system-generation  process. 
Because  of  the  detailed  simulation  intrinsic  to  a  CASE  simulation, 
the  package  was  used  extensively  for  a  nunber  of  years.  While  CASE 
continues  to  be  useful  in  nany  CPE  studies,  the  extreme  complexities 
of  systems  with  a  high  degree  of  parallelism  have  challenged  the 
validity  of  many  results  of  CASE  simulations  of  such  systems. 

Discrete  simulation  modeling's  primary  advantage  is  the 
flexibility  of  the  programming  languages  available  as  a  medium  for 
building  the  models.  With  the  proper  choice  of  the  host  language, 
one  can  build  a  comprehensive  simulation  model  that  faithfully  repre¬ 
sents  virtually  any  system.  Furthermore,  since  the  size  of  a  model 
is  only  limited  by  the  capability  of  a  machine  to  handle  large 
programs,  this  technique  may  be  used  to  model  deterministic  systems 
(or  nondetermini s tic  systems)  which  might  be  too  large  to  model 
effectively  by  other  techniques. 

The  major  drawback  of  the  discrete  simulation  language 
model  is  its  high  cost,  both  in  development  and  use.  The 
development  costs  are  generally  high  for  two  reasons.  First, 


the  simulation  model  itself  represents  a  significant  piece  of  soft¬ 
ware.  Since  software  development  is  labor  intensive,  the  costs  of 
sinply  writing  the  programs  tend  to  be  high.  Furthermore,  if  the 
systems  being  simulated  are  ccrpl ex  then  the  program  logic  will  also 
be  complex,  making  program  debugging  difficult.  Hie  second  reason 
for  high  development  costs  is  the  need  for  careful  model  verification 
and  validation.  Even  if  the  software  is  completely  debugged,  it  is 
often  difficult  to  verify  that  the  program  faithfully  evaluates  the 
model  designed  for  the  customer.  There  is  no  guarantee  that  the 
model  as  designed  is  truly  representative  of  the  system  being  studied. 
Therefore,  before  the  model  is  used  in  a  production  mode,  careful 
validation  is  necessary  to  insure  useful  results.  For  a  large  system 
model,  this  process  can  take  several  weeks,  thereby  driving  costs 
even  higher.  The  final  cost  factor  is  the  cost  of  production  use. 
While  the  computer  resources  required  to  run  the  model  depend  upon  the 
model's  level  of  detail  and  size,  even  a  small,  high-level  model  can 
require  many  central  processer  time  units  for  each  unit  of  simulated 
time.  FOr  example,  if  an  analyst  needs  to  simulate  ten  minutes  of 
oonputer  system  time  on  the  system  being  modeled  and  studied,  a  simula¬ 
tion  run  may  easily  require  five  or  six  times  that  in  CPU  time  alone. 
Furthermore,  since  many  simulation  languages  require  very  large  run¬ 
time  systems,  even  a  relatively  snail  model  may  require  a  large 
memory  allocation  —  and  correspondingly  increased  resource  costs. 

Despite  the  high  costs  involved,  the  capability  of  building 
large  deterministic  models  of  computer  systems  is  almost  unique 
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to  the  discrete  simulation  methodology.  Thus,  simulation  models  have 
found  wide  application  in  almost  every  sector  of  the  ccrmunity  of 
large-scale  computer  users.  ( [MacDougall,  1970]  is  an  excellent  survey 
paper  discussing  computer  system  simulation  in  more  detail  than  is 
appropriate  for  this  Thesis.  This  paper  also  contains  an  extensive 
annotated  bibliography.).  However,  though  used,  discrete  simulation 
models  are  often  boo  expensive  for  use  in  studying  less  expensive 
systems,  a  fact  which  has  resulted  in  the  decreasing  emphasis  of 
discrete  simulation  in  favor  of  analytic  queueing  models,  with  a 
corresponding  sacrifice  in  flexibility  and  determinism. 

Analytic  Modeling 

Within  the  context  of  this  paper,  analytic  modeling  refers 
to  a  technique  in  which  the  system  being  modeled  is  represented 
by  a  mathematical ,  rather  than  a  simulation,  model.  In  this 
approach,  the  analyst  seeks  to  find  a  mapping  to  the  interactions 
generic  from  the  system  under  study  to  a  set  of  mathematical  formulae 
which  can  be  analytically  solved.  A  large  nunber  of  techniques  fall 
into  the  analytic  modeling  category,  including  many  methods  used  in 
operations  research,  such  as  linear  and  integer  programming,  re¬ 
gression  analysis,  and  queueing  network  models.  Brice  [Brice,  1973] 
discusses  mathematical  models  in  detail  as  they  relate  to  CPE,  and 
the  reader  is  referred  to  his  work  for  more  conceptual  background. 

In  this  thesis,  however,  the  only  analytical  technique  which  will 
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be  discussed  is  the  queueing  network  model. 

The  queueing  network  modeling  methodology  was  originally 
developed  within  the  operations  research  ccmmunity  as  a  means  of 
analyzing  systems  which  display  certain  characteristics  of  random 
variability.  In  1963,  Jackson  [Jackson,  1963]  discovered  a 
powerful  technique  for  analytically  solving  queueing  network  models 
which  met  certain  criteria.  These  concepts  were  independently 
discovered  a  few  years  later  by  Gordon  and  Newall  [Gordon  and  Newall, 
1967].  Between  1970  and  1976,  researchers  within  the  CPE  camnunity 
extended  the  known  concepts  of  the  queueing  network  model  and 
developed  what  is  now  a  powerful  analytic  technique  for  CPE.  As  a 
result  of  these  developments,  both  the  research  and  industrial 
communities  have  been  able  to  develop  efficient,  user-oriented 
software  packages  for  automated  queueing  network  analysis,  making 
the  queueing  network  model  the  most  important  CPE  modeling  technique 
in  use  today. 

The  greatest  advantage  of  the  queueing  network  model  is  its 
simplicity.  The  concepts  sure  well-defined  and  may  require  minimal 
training  to  apply  them.  User-oriented  systems  exist  which  can 
run  on  most  large  oorrputer  systems;  and  models  of  even  large  multi¬ 
processor  systems  can  be  constructed,  tested,  and  validated  in  a 
very  short  time  compared  to  the  time  required  to  model  the  same 
system  using  discrete  simulation.  Also,  since  the  solution  is 
analytic  rather  than  experimental,  queueing  network  models  often 
require  less  ccrputer  resources  than  other  CPE  methods  might  require 
to  obtain  comparable  results.  This  inherent  simplicity  of  the 
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queueing  model  network  methodology  has  made  queueing  network 
modeling  by  far  the  least  expensive  modeling  method  discussed  in 
this  thesis. 

Despite  the  utility  and  simplicity  of  the  queueing  network 
model/  the  model  is  limited  in  three  areas:  (1)  the  model  is  probabi¬ 
listic  in  nature  and  unable  to  model  deterministic  processes;  (2)  the 
model  cannot  exactly  represent  certain  types  of  problems  inherent  to 
many  parallel  processes;  and  (3)  the  validity  of  the  model  is  depen¬ 
dent  upon  the  representation  of  the  data  used  to  generate  the 
probabilistic  functions  upon  which  the  model  is  based.  The  first 
limitation  causes  two  difficulties.  First,  there  are  some  problems, 
such  as  those  dealing  with  logic  design  and  hardware  architecture 
analysis,  which  require  detailed,  deterministic  analysis.  These 
problems  are  not  easily  solved  using  queueing  networks.  Secondly, 
there  are  many  CPE  problems  for  which  it  would  be  desirable  to  build 
a  model  which  could  be  either  deterministic  or  probabilistic,  depen¬ 
ding  upon  the  data  available  and  the  objectives  of  the  analysis. 

The  second  limitation  area  is  caused  by  several  inherent 
characteristics  of  the  queueing  model  pointed  out  by  [Browne,  et  al, 
1973] ,  who  experienced  difficulties  when  modeling  a  disk  input/output 
subsystem  with  the  disk  SEEK: READ /WRITE  overlap  feature.  The 
difficulties  included:  (1)  queueing  networks  only  approximate 
the  simultaneous  holding  of  multiple  resources  (such  as  when  both 
a  controller  and  a  disk  unit  must  be  held  by  the  same  transaction, 
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though  not  necessarily  for  the  same  period  of  time);  (2)  queueing 
networks  can  only  approximate  problems  enoountered  by  process 
blocking  (such  as  might  happen  when  a  disk  seek  has  been  initiated 
by  a  controller  but  is  busy  when  the  seek  is  complete,  blocking 
the  original  transaction  from  completion) ;  and  (3)  queueing 
networks  are  limited  in  capability  to  model  condition-dependent 
paths  in  which  the  conditions  are  dependent  upon  more  than  the 
location  in  the  network  (this  is  a  result  of  the  dependance  of 
much  of  queueing  network  theory  upon  the  memoryless  property  of 
Markovian  systems. 

The  final  area  of  limitation,  that  the  validity  of  the 
model  is  dependent  upon  the  validity  of  the  probabilistic  functions 
used,  is  cannon  to  all  probabilistic  systems.  Seme  problems  have 
been  resolved  by  the  discovery  that  some  of  the  cannon  functions 
are  relatively  insensitive  to  inaccuracies  in  the  data  used 
to  determine  functional  parameters  (such  as  the  mean  of  an 
exponential  or  negative  exponential  function).  While  few  researchers 
would  claim  that  one  could  depend  upon  the  results  of  a  queueing 
network  model  for  exact  accuracy,  many  experiments  have  shown  that 
a  well-designed  queueing  network  model  can  be  assumed  to  be  accurate 
to  within  ten  to  fifteen  percent,  or  better.  Furthermore,  by  com¬ 
bining  the  results  of  queueing  network  analysis  which  such  statis¬ 
tical  techniques  as  analysis  of  variance  and  confidence  intervals, 

CPE  practitioners  have  shown  the  queueing  network  model  to  be  a 
useful  tool  for  those  problems  which  it  is  capable  of  modeling. 
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Trace-Driven  Modeling 

Trace-driven  modeling  is  "a  technique  vrfiich  ocmbines 
measurement  and  simulation  for  the  purpose  of  evaluating  and  pre¬ 
dicting  the  performance  of  systems"  [Sherman,  1972],  In  particular, 
a  trace-driven  model  is  one  which  may  be  driven  by  either  actual 
workload  data  or  specially-massaged  trace  data  from  the  operational 
history  of  the  system  under  study.  For  example,  a  queueing  model 
could  be  designed  as  a  trace-driven  model  if,  instead  of  having 
the  workload  represented  by  a  stochastic  process,  the  input  to  the 
network  were  fed  directly  from  a  system  log  of  actual  transaction 
times.  Such  a  modeling  tool  has  obvious  application  in  a  variety 
of  performance  analysis  problems,  particularly  in  the  analysis  of 
system  algorithms  or  hardware  configurations. 

The  most  significant  work  in  trace-driven  models  was  that 
of  Anderson  [Anderson,  1974],  Sherman  [Sherman,  1972],  and  Browne, 
[Sherman  and  Browne,  1973;  Sherman,  Howard  and  Browne,  1975]  between 
1969  and  1974  at  the  University  of  Texas  at  Austin.  The  dissertations 
of  Anderson  and  Sherman  are  devoted  to  the  development  and  use  of 
the  trace-driven  modeling  concepts.  Sherman  demonstrated  the  useful¬ 
ness  of  trace-driven  modeling  by  building  and  using  a  trace-driven 
FORTRAN  simulation  model  of  the  University  of  Texas'  UT2  CDC  6600 
operating  system.  Anderson  developed  a  unified  trace-driven  modeling 
methodology  based  upon  the  System  Program  Graph  (SPG).  The  SPG 
is  a  graph-based  representation  technique  vhich  not  only  allows 
the  workload  to  drive  the  model  directly,  but  also  allows  the  model 


itself  to  be  represented  in  terms  of  a  data  structure  rather  than 
a  computer  program. 

Both  Anderson  and  Sherman  demonstrated  the  primary  advan¬ 
tage  of  the  trace-driven  technique:  the  results  are  not  subject 
to  either  the  smoothing  or  random  behavior  effects  of  using 
stochastic  methods  since  the  inputs  to  the  model  cure  deterministic, 
rather  than  stochastic.  Since  stochastic  processes  are  built  to 
represent  "average"  behavior,  these  processes  often  complicate  the 
investigation  of  systems  in  which  small  pertubations  are  important 
to  system  performance  evaluation.  The  trace-driven  model  overcomes 
most  of  these  difficulties  by  using  deterministic  data. 

A  second  advantage  of  trace-driven  modeling  is  that  the 
level  of  detail  of  the  simulation  results  may  be  controlled  by 
varying  the  detail  of  the  input  data,  rather  than  by  redesigning  and 
reprograrrming  the  model,  which  would  be  required  by  simulation  or 
queueing  network  models. 

Finally,  Sherman  observed  that  the  trace-driven  model 
results  generally  displayed  high  accuracy  which  could  often  be  vali¬ 
dated  by  straightforward  means.  This  accuracy  resulted  in  absolute, 
rather  than  relative,  measures  of  performance.  In  other  words, 
analysis  of  two  algorithms  could  yield  the  absolute  result  that 
algorithm  A  was,  say,  ten  percent  faster  than  algorithm  B  (for 
the  data  given) ,  rather  than  the  relative  result  that  algorithm  A 
was  simply  better  than  algorithm  B. 


14 


Despite  these  and  other  advantages,  trace-driven  modeling 
has  had  only  limited  practical  application.  One  key  reason  is  that 
the  usefulness  of  the  technique  depends  completely  upon  the  accuracy 
of  the  trace  data  and  the  quality  of  the  model  that  the  trace  data 
drives.  Accuracy  of  trace  data,  of  course,  is  a  problem  not  unique 
to  this  methodology,  since  both  discrete  simulations  and  analytic 
models  are  dependent  upon  the  same  data.  The  problem  tends  to  be 
more  significant,  however,  with  a  trace-driven  model  because  the 
trace-driven  model  tends  to  be  more  sensitive  to  minor  pertubations 
in  the  data,  whereas  the  smoothing  effect  of  stochastic  processes 
tends  to  eliminate  the  impact  of  these  pertubations  for  other  meth¬ 
ods.  The  quality  of  the  model  that  the  trace  data  is  driving  is  not 
only  a  function  of  correct  model  architecture,  but  it  is  primarily 
a  function  of  the  modeling  capabilities  of  the  model  itself.  For 
example,  if  the  model  used  is  a  queueing  network  model,  the  trace- 
driven  nature  of  the  approach  does  not  absolve  the  model  from  all  of 
the  limitations  found  with  queueing  network  models. 

Like  the  queueing  model,  the  SPG  method  is  limited  in  its 
capability  to  model  deterministic  processes.  Furthermore,  the  SPG 
model  of  a  carpi ex  system  nay  easily  be cane  unwieldy  because  of 
the  number  of  nodes  included.  These  and  other  weaknesses  have 
resulted  in  very  little  application  of  the  SPG  or  other  similar 
trace-driven  modeling  methods,  although  Anderson's  and  Sherman's 
work  have  helped  to  lay  an  effective  groundwork  for  the 
development  of  the  TEFN  structure. 


CHAPTER  III 


DESCRIPTION  OF  THE  PETRI  NET  MODEL 

The  Petri  net  is  an  abstract  model  of  information  flow 
first  preposed  by  Carl  Petri  in  Germany,  in  1964  [Petri,  1964]. 

The  Petri  net  was  first  applied  to  the  study  of  computer  system? 
by  Holt  and  Commoner  [Holt,  et.al. ,  1968;  Commoner,  et.al. ,  1971], 
in  1968,  and  subsequently  enjoyed  considerable  interest  within  the 
Computation  Structures  Group  of  Project  MAC,  from  1968  to  1975. 

Since  1968,  Petri  nets  have  been  studied  and  used  both  in  university 
and  industrial  environments  to  study  and  design  circuits,  algorithms, 
systems,  and  other  processes.  In  1977,  this  research  was  the  subject 
of  a  survey  paper  published  in  the  ACM  Computing  Surveys  [Peterson, 
1977] ,  to  which  the  reader  is  referred  for  more  background  information. 

Definition  of  the  Petri  Net 

Figure  3-1  is  a  graphical  representation  of  a  Petri  net. 


Figure  3-1  Example  Petri  Net 
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Informally,  the  Petri  net  is  a  graph  structure  consisting  of  two 
types  of  nodes,  places  (pictured  by  circles)  and  transitions  (pic¬ 
tured  by  vertical  bars),  connected  by  directed  arcs.  Definition  3-1 
formalizes  the  Petri  net  concepts  pictured  in  Figure  3-1. 


Definition  3-1.  Petri  Net 

A  Petri  net  is  defined  as  a  bipartite,  directed  graph 
described  by  the  four-tuple,  C  -  (P,T,I,0),  where, 

P  =  (P1/.../Pn),  a  set  of  places,  n>0; 

T  =  ft^,...,t  ],  a  set  of  transitions,  m?0; 

p 

I  is  the  transition  input  function,  I:T-*2 

D 

0  is  the  transition  output  function,  0:T— 2  ;  and, 
sets  P  and  T  are  disjoint. 


In  this  definition,  the  connecting  arcs  are  defined  by  the  transition 
input  and  output  functions,  since,  for  each  transition,  the  input 
function  will  yield  the  set  of  places  connected  by  arcs  directed  into 
the  transition,  while  the  output  function  yields  the  set  of  places 
connected  to  the  transition  by  arcs  directed  away  from  the  transition. 

Using  this  definition,  the  structure  of  the  Petri  net  of 
Figure  3-1  would  be  specified  as  follows: 


RIET=(P,T,I,0) ,  where, 


P  «  fPl,P2,P3,P4,P5,P6} 


T  =  [T1,T2,T3,T4) 


1(T1)  *  {P1,P2} 
I(T2)  =  fP3,P45 
I(T3)  «  {P5J 
I(T4)  «  (P6J 


0(T1)  ■  (P3J 
0(T2)  *=  {P5J 
0(T3)  =  fP6T 
0(T4)  «  (P2,P4^ 
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At  this  point,  it  is  important  to  understand  that  the  places  and 
transitions  of  a  Petri  net  are  primitive  objects,  with  no  associated 
attributes,  functions,  or  other  special  meaning. 


Marked  Petri  Net  Models 


The  Petri  net  structure  may  be  used  to  represent  the  struc¬ 
ture  of  information  or  execution  flow  in  a  process,  but  any  study  of 
the  dynamic  or  state  properties  of  a  system  requires  the  intro¬ 
duction  of  another  entity,  the  token. 

A  token  is  a  dimensionless,  uninterpreted  object  which  may 
"reside"  at  any  place  within  the  network.  The  number  of  tokens  at  a 
given  place  is  referred  to  as  the  marking,  or  state,  of  that  place, 
and  the  vector  of  markings  of  all  places  defines  the  marking,  or 
state,  of  the  entire  network. 

Figure  3-2,  below,  is  a  marked  Petri  net,  with  tokens 
being  represented  by  dots  within  the  marked  places.  This  marking 
would  be  specified  by  the  following  vector: 

M  =  (0,  1,  0,  1,  0,  0) 


where. 


M. 


the  number  of  tokens  currently  residing  at  place  i. 


Interpreted  Petri  Net  Models 


If  a  Petri  net  is  used  to  model  a  specific  system,  it  is 
necessary  to  assign  a  name  or  interpretation  to  each  node  of  the 
network,  resulting  in  an  interpreted  Petri  Net.  This  interpretation 
then  ascribes  meaning  not  only  to  the  nodes  of  the  network  but  to 
the  network  states,  or  markings.  The  net  of  Figure  3-2  could,  for 
example,  be  interpreted  so  as  to  represent  a  simple  disk  subsystem. 
With  this  interpretation,  shown  on  Figure  3-3,  the  narking  above 
might  represent  the  state  in  which  (a)  there  is  one  pending  disk 
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requests  and,  (b)  both  a  disk  unit  and  a  controller  are  available. 

Execution  of  the  Petri  Net  Model 

When  all  of  the  places  ocnprising  a  transition's  input  set 
have  a  non-zero  marking,  the  transition  is  said  to  become  enabled, 
ready  to  fire,  or  "happen. "  If  a  disk  request  "arrives"  at  place  PI 
(from  Figure  3-3),  transition  T1  will  be ccrne  enabled,  and  a  firing 
occurs. 

A  firing  occurs  deterministically  when  the  specified  tran¬ 
sition  is  enabled  and  involves  the  following  firing  rule:  one 
token  is  removed  from  each  of  the  input  places  and  a  new  token  is 

With  this  initial  marking  the  Petri  net  would  model  a  single- 
controller,  single-disk  subsystem.  A  layer  subsystem  could  be 
modeled  by  the  same  structure  by  adding  more  controller  or  disk 
tokens  to  the  initial  narking. 


created  and  placed  at  each  output  place.  Figure  3-4  illustrates  the 


results  firing  transition  Tl  for  the  Petri  net  of  Figure  3-3, 
after  a  new  token  has  been  introduced  into  the  net  at  place  PI. 

Disk  Bequest  arrives; 


Figure  3-4  Petri  Net  After  Tl  Fires 


The  Petri  Net  as  a  CPE  Tool 


In  1972,  Dr.  Jerre  Noe  [Noe,  1971]  of  the  University  of 
Washington  considered  the  potential  of  the  Petri  net  as  a  tool 
for  performance  modeling.  By  building  a  model  of  a  CDC  6400  operating 
system  and  using  it  to  study  seme  basic  performance  characteristics, 
Noe  illustrated  that  the  Petri  net  has  several  attractive 
properties  that  make  it  a  potentially  tool  powerful  modeling.  The 
most  important  of  these  is  the  inherently  deterministic  nature  of 
the  model,  characteristic  gives  the  model  representational  accuracy 
not  possessed  by  stochastic  models  (such  as  the  queueing  network 
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model).  A  second  property  is  the  Petri  net's  ability  to  represent 
a  system  in  varying  degrees  of  detail  within  the  same  net. 

This  characteristic  affords  considerable  modeling  flexibility  without 
a  corresponding  decrease  in  representational  accuracy. 

Despite  its  advantages  over  other  CPE  tools,  the  Petri  net 
has  yet  to  become  a  widely  applicable  CPE  instrument.  The  primary 
reason  is  that  the  model  lacks  a  crucial  attribute  required  in 
ccnputer  performance  analysis:  an  intrinsic  time-resolution  mech¬ 
anism.  There  is  no  concept  of  measurable  time  for  a  Petri  net 
execution  sequence,  and  so  it  is  inpossible  to  measure  such  things  as 
throughput  rates  and  response  times.  In  addition  to  the  time 
measurement  problems,  there  is  no  mechanism  to  naturally  represent 
the  flow  of  specific  information  across  transitions,  since  all 
tokens  created  at  firing  time  are  totally  independent  of  any  other 
tokens  already  in  the  system.  While  this  is  not  an  insurmountable 
problem,  it  does  make  the  modeling  of  processes  much  more  difficult, 
particularly  when  dealing  with  multiple  conditional  paths. 

The  Evaluation  Net  Model  (E-Net.) 

Although  the  Petri  Net,  per  se,  did  not  prove  a  methodol¬ 
ogy  sufficiently  powerful  for  modeling  the  performance  of  computer 
systems,  one  of  Noe's  doctoral  students,  Gary  Nutt  [Noe  and  Nutt, 

1972  and  1973],  used  the  Petri  net  concepts  to  develop  a  new  structure 
which  would  retain  positive  properties  of  the  Petri  net  while  over- 
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caning  some  of  its  limitations.  The  result  was  the  Evaluation  Net, 
or  E-Net.  This  structure  changed  several  of  the  basic  concepts  of 
the  Petri  net  and  added  quite  a  few  new  features,  resulting  in  a 
more  complex  modeling  tool.  Among  the  changes  included  were: 

(1)  The  concept  of  time  was  implemented  by  "delaying"  tokens 
at  the  transitions.  The  amount  of  time  was  determined  by  a  "transi¬ 
tion  procedure"  and  controlled  by  a  global  timing  mechanism. 

(2)  In  addition  to  determining  firing  delays,  the  transition 
procedures  manipulated  tokens  and  certain  global  variables. 

(3)  A  set  of  global  "environment  variables"  was  specified 
and  used  in  conjunction  with  transition  procedures,  "resolution 
procedures,"  and  other  functions. 

(4)  Conflicts  between  paths  were  resolved  using  special 
resolution  procedures  activated  at  transition  firing  time. 

(5)  Resolution  procedures  were  also  associated  with  a 
special  class  of  nodes  utilized  to  aid  in  resolving  ambigir  ties 
throughout  the  network.  These  nodes  contained  resolution  infor¬ 
mation  defined  by  the  user  of  the  system. 

(6)  Some  tokens  were  made  global.  This  change,  though  quite 
significant,  was  required  by  the  inplementation  of  time  in  the 
transitions  instead  of  the  places. 

The  primary  importance  of  the  E-Net  is  that  it  was  the 
first  major  attempt  at  developing  a  Petri-net-based  modeling  system 
for  CPE  applications.  While  the  E-Net  did  not  meet  with  wide 
acceptance  as  a  usable  tool,  it  did  show  that  Petri  net  properties 
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could  be  at  least  partially  preserved,  and  that  a  simpler  Petri-net- 
based  structure  might  be  useful.  The  primary  drawback  of  the 
system  was  its  tremendous  complexity,  which  made  even  small  mod¬ 
eling  efforts  a  major  production  to  all  but  the  true  expert.  This 
complexity  is  contrasted  with  modeling  with  queueing  networks, 
which  requires  a  relatively  small  amount  of  expertise  to  construct 
a  reasonable  and  useful  model. 

Even  with  its  rather  cumbersome  complexity,  however, 

Nutt's  work  represented  an  effective  pioneer  effort  to  the  goal  of 
developing  and  implementing  a  Petri-net-based  CPE  model. 


CHAPTER  IV 


THE  TIME-EXTENDED  PETRI  NET:  BASIC  CONCEPTS 

The  Time-Extended  Petri  Net  (TEEN )  is  a  modeling  structure 
based  upon  the  Petri  net  and  designed  to  meet  the  goals  expressed 
earlier  in  this  Thesis.  The  advantages  of  the  Petri  net,  in  partic¬ 
ular  those  of  inherent  parallelisn  and  determinism,  have  been  re¬ 
tained,  while  the  representational  capabilities  have  been  extended 
by  implementing  places,  transitions,  and  tokens  in  more  elaborate 
forms. 

The  Petri  net  has  been  extended  to  allow  for  the  natural 
representation  of  time- resolved  behavior  (changes  to  the  token  and 
place  objects)  and  state-dependent  execution  paths  (changes  to 
the  token  and  transition  objects).  The  TEEN  places  and  transitions 
are  given  attributes  which  allow  the  direct  definition  of  perfor¬ 
mance  metrics  as  an  inherent  characteristic  of  a  model.  Final ly , 
the  TEEN  token  is  defined  as  a  messenger  for  activating  the  places 
and  transitions. 

Both  the  definition  and  placement  of  all  TEEN  attributes 
are  predicated  upon  a  CEE  rather  than  a  theoretical  view  of  the 
Petri  net.  This  view  defines  an  inherent  interpretation  in  which  places 
represent  processes  and  queues,  while  transitions  remain  as  synchro¬ 
nization  primitives  that  act  as  state  transition  arcs.  Transitions 
never  represent  either  processes  or  queues,  nor  are  they  ever  part  of 
the  state  definition  of  a  particular  TEEN  model.  Because  of  this  inter- 
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pretation,  time  resolution  mechanisns  are  implemented  completely  within 
the  place.  This  includes  a  place  clock,  internal  place  queues,  and  a 
token  delay  time  function.  In  support  of  the  token  delay  time  function 
within  the  place,  tokens  have  been  extended  to  allow  them  to  carry 
external  parameters,  which  can  be  used  by  the  place  token  delay  time 
function  to  compute  internal  queueing  delays.  Similarly,  transitions 
have  been  equipped  with  special  token  templates  to  insure  that  when 
tokens  are  created  at  transition  firing  time  the  tokens  will  contain 
values  for  the  parameters  required  to  compute  the  token  delay  time 
within  the  place. 

Implementation  of  state  dependent  execution  paths  requires 
a  token  routing  mechanisn  capable  of  resolving  state  conditions  upon 
which  the  token's  path  is  dependent.  Since  this  mechanism  affects 
the  order  of  state  transitions,  it  is  implemented  in  the  form  of  an 
extension  to  the  Petri  net  transition  cad  led  a  firing  template.  Along 
with  a  corresponding  extension  to  the  Petri  net  token,  the  type  attri¬ 
bute,  the  firing  template  allows  for  deterministic  token  routing  and 
provides  a  mechanism  to  model  the  effects  of  process  blocking. 

4 

Finally,  the  token  type  attribute  provides  an  effective 
mechanism  for  resolving  the  workload  of  systems  into  components  or 
activities.  Wiile  this  does  not  inherently  increase  the  modeling 
power  of  the  TEFN,  it  does  afford  the  practical  advantage  of  being 
able  to  collapse  certain  very  large  Petri  net  models  vhich  do  not 
employ  token  types  into  highly  compact  models  with  multiple  token 


types.  An  example  of  this  compaction  capability  is  illustrated  in 
the  example  TEW  model  of  chapter  six. 

Throughout  this  research,  the  author  has  taken  great  care 
to  retain  the  modularity  and  subnetwork  independence  characteristic 
of  the  Petri  net.  Detensions  vhich  create  global  environments  (such 
as  a  global  synchronizing  clock,  global  tokens,  etc.)  were  avoided, 
as  were  modifications  which  precluded  reducibility  of  the  TEPN  into 
a  Petri  net,  in  the  default  case.  Despite  these  efforts  the  TEPN 
structure  has  neither  the  simplicity  nor  the  elegance  of  the  Petri 
net.  However,  it  does  appear  to  be  a  powerful  model  which  remains 
straightforward  enough  to  be  readily  usable. 

TEEN  General  Definition 

The  basic  definition  of  the  TEEN  model,  definition  4-1 
below,  is  structurally  equivalent  to  that  of  the  Petri  net,  defi¬ 
nition  3-1,  in  chapter  three.  The  Petri  net  places  and  transitions 
are  simple  primitives  with  mo  dimensions  or  attributes.  Similarly, 
the  token  is  only  a  "marker,"  with  no  "meaning"  of  its  own.  The 
TEEN  structure  has  the  same  building  blocks  but  they  are  no  longer 
simple  primitives.  Rather,  they  are  potentially  complex  structures 
with  well-defined  attributes.  An  analogous  situation  might  be  found 
in  the  structure  of  chemical  molecules.  All  molecules  are  built  of 
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a  basic  building  block,  the  atom.  For  quite  a  few  years,  the  atom 
was  thought  of  as  a  primitive — i.e. ,  it  could  not  be  broken  down 
further.  Then  scientists  discovered  subatomic  particles  which  are 
now  known  to  be  building  blocks  for  the  atom.  The  new  atomic  model 
is  able  to  explain  a  larger  number  of  phenomena.  But,  in  cases 
where  the  subatomic  particles  do  not  make  any  difference,  the  simpler 
model  is  still  used  and  does  not  compromise  the  integrity  of 
the  more  complex  structural  representation. 

In  like  manner,  the  TEPN  model  is  able  to  represent  many 
system  interactions  which  oould  not  be  modeled  with  the  Petri  net. 
Wien  the  additional  modeling  power  of  the  TEFN  is  unnecessary,  how¬ 
ever,  the  TEPN  model  may  be  treated  as  equivalent  to  the  simpler 
Etetri  net  by  allowing  the  more  complex  TEPN  places,  transitions,  and 
tokens  to  default  to  their  simplest  form. 

Definition  4.1.  Time-Extended  Petri  Net 

A  Time-Extended  Petri  Net  (TEPN)  is  a  modeling  structure 
defined  by  the  four-tuple,  C  =  (P,T,I,0),  where, 

P  *  [pj,...,pn] ,  a  set  of  places,  nzO? 

T  =  {t^,...,^,  a  set  of  transitions,  m»0; 

I  is  the  transition  input  function,  1:T— 2 

p 

0  is  the  transition  output  function,  0:T— 2 
sets  P  and  T  are  disjoint. 

The  next  three  sections  define  each  of  the  TEPN  building 
blocks:  The  TEPN  place,  transition,  and  token. 
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TEPN  Place  Definition 

The  state  of  both  the  Petri  net  and  the  TEFN  is  determined 
by  the  states  of  the  places  within  the  particular  net„  The  tran¬ 
sition,  on  the  other  hand,  is  a  network  element  that  controls 
state  changes  across  the  net-  In  this  section,  I  discuss  the 
attributes  of  the  TEFN  place-  These  attributes,  all  extensions  from 
the  primitive  place  concept  found  in  a  Petri  net,  heavily  influence 
the  domain  of  problems  to  which  the  TEPN  may  be  successfully  applied, 
while  many  of  the  extensions  to  the  transition  affect  the  solution 
net's  structure - 

There  are  two  project  goals  which  led  to  the  major  exten¬ 
sions  to  the  Place  definition-  The  first  relates  to  the  need  for  a 
node ling  basis  capable  of  representing  time-resolved  behavior  of 
networks  of  processes-  The  Petri  net  models  structures  and  struc¬ 
tural  relationships.  With  the  Petri  net,  one  can  study  paths  of 
both  data  flew  and  control  flow  through  systems  of  considerable 
complexity;  the  Petri  net  also  offers  a  precise  notation  for 
describing  the  syntax  of  such  system  problems-  A  Petri  net  cannot, 
however,  describe  the  time-resolved  behavior  of  a  real  system. 
Modeling  such  problems  necessitates  that  the  model  incorporate  the 
concept  of  time  and  timed  performance - 

The  second  project  goal  is  developing  a  modeling  structure 
which  provides  a  natural,  but  powerful  mechanism  for  defining  and 
studying  various  performance  metrics  within  the  model  itself.  Sinoe 
virtually  all  performance  metrics  are  defined  in  terms  of  the  state 


history  of  the  model,  this  goal  involves  the  capture  of  state  history 
information  for  each  of  the  TEFN  places. 


The  TERJ  place  conceptual  ly  combines  the  concepts  of 
queues  and  servers.  Functionally,  the  place  receives  tokens  from 
input  transitions,  "stores"  the  tokens  for  some  elapsed  interval, 
and,  when  an  appropriate  output  transition  is  enabled  and  fires,  it 
"emits"  the  same  token  to  the  output  transition.  In  a  CPE  model, 
places  might  be  abstractions  of  the  resources  or  processes  which 
do  not  create  or  destroy  tokens;  they  act  as  a  "way  station"  for 
tokens  between  token  creation  (at  the  firing  of  the  input  transition) 
and  token  destruction  (at  the  firing  of  the  output  transition). 

This  definition  underscores  three  characteristics  unique  to  the 
place.  These  three  are: 

(1)  Tokens  only  reside  at  places,  with  the  result  that  the 
state  of  a  net  may  be  defined  in  terms  of  the  states  of  places 
within  the  net; 

(2)  The  place  conserves^  tokens  and  could,  if  so  implemented, 
allow  tokens  to  retain  a  unique  identity;  and 

(3)  While  there  is  no  concept  of  time  intrinsic  to  the  Petri 
net,  there  is  definitely  a  concept  of  "waiting,"  in  that  a  token 
resides  at  a  place  until  it  is  moved  by  the  firing  of  a  transition. 

^Although  places  conserve  tokens  —  i.e. ,  tokens  are  neither  lost 
nor  added  —  this  should  not  be  confused  with  network-wide  token 
conservation  as  discussed  in  Petri  net  literature  [Lien,  1976] 
and  [Pererson,  1977]. 
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These  characteristics  can  be  combined  with  a  time  mecha¬ 
nism  to  provide  a  well-formed  basis  for  modeling  time-resolved 
behavior.  The  TEPN  place  has  been  extended  from  the  Petri  net  place 
to  include  an  internal  clock  and  other  attributes  to  effectively 
support  such  a  mechanism.  In  defining  these  attributes,  we  start 
with  the  TEPN  Place  definition. 


Definition  4.2  TEPN  Place 

The  TEPN  Place  is  a  composite  object  which  receives  tokens  from 
adjacent  transition  nodes  and  emits  the  same  tokens  bo  adjacent 
output  transition  nodes.  Each  place  is  internally  defined  by 
the  following  attributes: 

(1)  Place  Clock,  a  non-negative,  asynchronous 
clock; 

(2)  Place  Active  Queue  (PAQ),  a  queue  of  tokens  waiting 
to  become  enabled; 

(3)  Place  Enabled  Queue  (PEQ),  a  queue  of  tokens  waiting 
to  leave  the  place; 

(4)  a  set  of  Place  Performance  Functions. 

The  four  place  attributes  represent  what  the  author 
believes  to  be  the  minimal  extensions  necessary  to  give  the  TEPN 
place  the  flexibility  required  for  effectively  modeling  parallel 
systems.  As  such,  each  of  these  attributes  is  directly  linked  to 
the  objectives  discussed  earlier  in  this  section.  The  clock  pro¬ 
vides  time-resolution  without  which  most  of  the  performance  metrics 
would  lose  meaning.  The  two  queues  provide  a  concept  of  ordering 
as  well  as  potential  for  delays  (service  times)  and  internal  syn¬ 
chronization  (including  priority  schemes).  Finally,  the  performance 
functions  provide  a  natural,  intrinsic  napping  from  the  place  state 
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history  to  the  set  of  integers.  The  concept  of  the  "state"  of  a 
place  and  the  place  state  history  will  be  discussed  further  below. 

There  are  several  methods  for  defining  each  of  the  four 
place  attributes.  For  the  purpose  of  this  Thesis,  it  will  be  suffi¬ 
cient  to  present  the  subattributes  which  form  the  most  primitive 
characteristics  of  the  clock,  queues,  and  functions  mentioned  above. 

In  the  next  chapter  we  discuss  the  implementation  of  the  place  in 
terms  of  the  functions  which  must  be  programmed  in  the  implementation. 

Each  of  the  place  attributes  is  said,  for  the  purposes  of 
this  Thesis,  to  be  specified  as  one  of  two  types  of  subattributes: 
configuration  attributes  and  state  attributes.  Configuration  at¬ 
tributes  are  those  which  determine  the  place's  internal  structure 
and  operational  characteristics.  If  these  attributes  are  not 
ascribed  meaning  then  the  place  would  be  undefined.  An  example  of 
such  an  attribute  would  be  the  queueing  discipline  attribute  of  a 
queue.  A  queue  cannot  be  defined  or  used  unless  a  queueing  disci¬ 
pline  is  associated  with  it.  State  attributes,  on  the  other  hand, 
are  those  which  directly  affect  the  place's  state  when  they  change 
as  a  result  of  execution  of  a  network  and  movement  of  tokens  through 
the  place.  The  current  value  of  the  place  clock,  for  exanple,  would 
be  a  state  attribute. 

TEPN  Place  Clock 

This  clock  is  defined  as  a  simple  interval  clock  which  is 
undefined  for  negative  or  non-integer  values.  It  is  decreasing  in 
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that  whenever  it  has  a  positive  value  associated  with  it  it  auto¬ 
matically  and  asynchronously  decrements  by  units  until  the  value 
reaches  zero.  The  clock  has  no  configuration  subattributes,  and 
only  one  state  attribute,  called  TIME. 

Definition  4.3  State  of  a  TEPN  Place  Clock 
The  state  of  a  TEPN  place  clock  is  defined  as  the  current  non¬ 
negative  value  of  the  clock.  This  value  is  referred  to  as  the 
TIME,  and  is  functionally  denoted  TIME(P) ,  where  P  references 
the  place  whose  clock  is  being  observed. 

TEPN  Place  Active  Queue  and  Enabled  Queue 

A  queue  is  an  ordered  list  defined  by  an  ordering  function 
(queueing  discipline)  and  a  function  that  determines  service  time. 

A  queue  may  be  further  defined  to  include  a  maximum  size;  if  it  has 
this  attribute  and  the  maximum  size  is  finite,  the  queue  is  called  a 
bounded  queue.  The  queues  that  define  each  place  cure  queues  of  tokens 
which  are  received  by  the  place  during  execution  of  a  network.  The 
first  queue,  the  Place  Active  Queue  (PAQ),  accepts  tokens  immediately 
upon  their  entry  into  the  place.  The  service  time  within  the  queue 
is  determined  by  a  function  called  the  Token  Delay  Time  Mapping 
(TDTM),  which  maps  the  attributes  of  the  token  into  the  set  of 
integers. 


Once  the  token  has  left  PA Q  it  enters  the  Place 


Enabled  &ieue  (PEQ).  Ihis  queue  has  no  service  time  function;  the 
"service  time"  is  determined  by  the  state  of  the  adjacent  output 
transitions.  When  one  of  these  transitions  is  ready  to  accept 
a  token,  the  PEQ  will  release  a  token  (if  one  is  available). 
Although  the  PEQ  does  not  have  an  interned,  ly  defined  service  time 
function,  it  may  have  a  queueing  discipline.  In  this  case,  certain 
tokens  will  be  considered  to  be  receiving  service  while  others 
will  be  considered  to  be  waiting,  although  the  service  time  will 
be  indeterminate,  since  it  depends  upon  the  length  of  time  the 
"enabled"  token  must  wait  for  an  output  transition  to  accept  the 
token. 

Definition  4.4  Place  Active  Queue 
The  Place  Active  Queue  (PAQ)  of  place  P  is  the  queue  of  tokens 
residing  within  place  P  which  will  not  be  available  to  leave  P 
prior  to  a  determinate  minimum  sequence  of  place  clock 
state  transitions.  The  PAQ  configuration  is  defined  by  the 
following  attributes: 

(1)  PAQ  queueing  discipline, 

(2)  PAQ  Bound,  and, 

(3)  PAQ  Token  Delay  Time  Mapping  (TDIM). 

Definition  4.5  Place  Enabled  Queue 


The  Place  Enabled  Queue  (PEQ)  of  place  P  is  the  queue  of 
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tokens  that  are  residing  within  place  P  and  which  cure  not  in 
the  FAQ.  The  configuration  of  the  PEQ  is  specified  by  two 
attributes: 

(1)  PEQ  Queueing  Discipline,  and, 

(2)  PEQ  Bound * 

These  two  definitions  clarify  both  the  functions  of  and  the 
conceptual  differences  between  the  two  queues.  The  first  queue 
deals  with  tokens  waiting  because  of  internal  delays  caused  by  the 
application  of  the  PAQ  TDTM;  the  second,  the  PEQ,  holds  the  tokens 
which  are  delayed  due  to  external  factors.  It  is  important  to 
note  at  this  point  that  the  place  not  only  has  no  control  upon 
these  factors,  but  also  has  no  visibility  on  them.  The  expected 
wait  time  within  the  PEQ,  therefore,  is  always  indeterminate  from 
the  viewpoint  of  the  particular  place. 

The  configuration  subattributes  of  the  two  place  queues 
are  described  further  below.  Except  where  noted,  the  corresponding 
subattributes  for  both  the  PAQ  and  PEQ  sure  conceptually  identical, 
although  in  iirp lementat ion  they  have  no  a  priori  relationship. 

PAQ  and  PEQ  Queueing  Discipline.  The  ordering  function, 
or  queueing  discipline  associated  with  each  of  the  place  queues  my 
be  either  a  "standard"  queueing  discipline,  such  as  first-come- 
first-served  (FCFS)  or  infinite  processor  (IP),  or  it  my  be  a 
specially  defined  function.  Regardless  of  how  it  works,  however, 
the  queueing  discipline  determines  both  hew  marry  tokens  my  be 
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"active"  or  "enabled"  at  any  given  time,  and  the  degree  of  depen¬ 
dence  or  independence  of  tokens  passing  through  the  same  place* 

One  result  of  this  is  that  the  queues  provide  a  natural  partitioning 
of  the  place's  resident  tokens  into  four  sets,  or  states.  For 
purposes  of  this  Thesis,  these  four  states  shell  1  be  defined  as 
follows: 

(1)  WAIT:  token  in  PAQ,  not  being  served 

(2)  ACTIVE:  token  in  PAQ,  being  served 

(3)  ENABLED-BLOCKED:  token  in  PEQ,  not  available  to 
leave  place 

(4)  ENABLED-READY:  token  in  PEQ,  available  to  leave 
place* 

Queue  Bound*  Each  of  the  queues  may  be  bounded  by  sane 
finite  value*  This  value  will  determine  the  maximum  size  to  which 
the  entire  queue  may  ever  grow.  The  queues  may  be  separately  or 
jointly  bounded.  A  joint  bound  treats  the  entire  place  as  a  large 
queue  by  stating  that  only  a  limited  number  of  tokens  may  reside 
within  a  place  at  any  given  time.  If  a  place  is  only  assigned  a 
joint  bound  then  there  is  no  restriction  upon  how  the  tokens  will 
be  distributed  among  the  two  queues.  In  addition  to  or  in  place  of 
an  explicit  joint  bound,  each  queue  may  be  separately  bounded.  If 
there  is  no  explicit  joint  bound  but  both  queues  are  bounded  then 
the  place  is  said  to  have  an  implicit  bound  equal  to  the  sun  of  the 
individual  queue  bounds.  If  there  is  an  implicit  or  explicit  joint 
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bound  then  the  place  is  said  to  be  bounded,  as  expressed  by  Defi¬ 
nition  4.6  below. 

Definition  4.6  Bounded  Place 

A  place,  P,  is  said  to  be  n-bounded  if  the  PAQ  and  FEQ  of 
P  are  jointly  bounded  by  n.  If  n  is  the  smallest  integer 
such  that  P  is  still  n-bounded,  then  n  is  said  to  be  the 
minimal  bound  of  P. 

The  concept  of  a  finitely  bounded  place  allows  modeling  of 
systems  which  have  severe  restrictions  upon  the  "processing"  capa¬ 
bility  of  specific  nodes,  or  which  display  performance  characteris¬ 
tics  very  sensitive  to  increased  "workload."  However,  it  should  be 
noted  that  while  no  real  systems  are  in  fact  infinite  servers  there 
are  systems  where  it  is  useful  to  determine  the  "natural"  steady 
state  conditions  that  would  exist  if  limits  did  not  exist.  There¬ 
fore,  there  are  many  cases  in  which  the  places  would  be  unbounded. 

Token  Delay  Time  Mapping  (TDTM) .  Each  Place  Active  Queue 
has  a  Token  Delay  Time  Mapping  (TDTM)  associated  with  it.  This 
attribute  defines  a  mapping  from  the  domain  of  tokens  into  the 
range  of  non-negative  integers,  and  determines  the  minimum  internal 
time  delay  required  before  the  token  may  become  enabled  and  enter  the 
Place  Enabled  Queue.  The  passing  of  this  time  delay  is  indicated  by 
caimensurate  changes  in  the  state  of  the  place  clock.  This  delay 
dpas  not  include  any  wait  time  experienced  prior  to  the  application 


of  the  function  to  the  token*  For  exanple,  if  the  queueing 
discipline  is  PCFS  (first-come- first-served) ,  then  tokens  would 
have  to  wait  in  line  until  the  PAQ  "server"  was  ready*  Then 
the  delay  TT7IM  would  be  applied  to  the  token  and  the  token  would 
reside  within  the  "server"  for  exactly  the  amount  of  delay  resulting 
from  the  application  of  the  token  function  to  the  token,  after  which 
it  would  be  released  to  the  PEQ. 

Definition  4*7  Place  Token  Delay  Time  Mapping 

The  Place  Token  Delay  Time  Mapping  (TDM)  is  a  transformation 

which  maps  the  domain  of  tokens  into  the  range  of  non-negative 

integers* 

The  State  of  the  PAQ  and  PEQ*  In  addition  to  its 
configuration  subattributes,  each  queue  has  an  implicit  set  of 
state  subattributes  which  define  the  state  of  the  queue  and  help 
to  define  the  state  of  the  place*  Definitions  4*8  and  4*9  define 
these  state  attributes. 

Definition  4*8  State  of  the  Place  Active  Queue 

The  state  of  the  place  active  queue  is  defined  by  the  following 

state  attributes: 

(1)  The  sequence  of  tokens  within  the  queue  in  the  WAIT 
state,  and 

(2)  The  sequence  of  tokens  within  the  queue  in  the  ACTIVE 


state 
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Definition  4.9  State  of  the  Place  Enabled  Queue 
The  state  of  the  place  enabled  queue  is  defined  by  the 
following  state  attributes: 

(1)  The  sequence  of  tokens  in  the  ENABLED-BLOCKED 
state,  and 

(2)  The  sequence  of  tokens  in  the  ENABLED-READY  state. 

TEPN  Place  Performance  Functions 

The  TEEN  Place  extensions  discussed  above  provide  for  a 
veil-defined  and  flexible  ability  to  model  time-resolved  behavior 
without  altering  the  basic  determinism  and  subnet  independence 
of  the  Petri  net.  The  final  extension  to  the  Petri  net  Place  is  a 
mechanism  to  introduce  the  definition  of  performance  metrics  into 
the  modeling  structure  itself.  This  aspect  of  the  TEPN  is  somewhat 
unique  from  most  modeling  methods  in  that  it  merges  the 
modeling  tools  with  the  data  analysis  tools,  thus  simplifying  the 
CPE  modeling  process.  This  mechanism  also  aids  the  analyst 
in  validating  the  model  by  providing  a  reliable  link  between 
the  model  and  the  model's  apparent  results.  In  other  words,  by 
allowing  for  predefined,  well-tested  interned  performance 
metrics,  the  TEPN  structure  definition  may  eliminate  many  of  the 
problems  encountered  when  the  output  has  not  been  sufficiently  vali¬ 
dated  to  assure  agreement  with  internal  results. 
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Definition  4.10  Place  Performance  Function 
A  Place  Performance  Function  is  a  mapping  frcm 
the  sequence  of  execution  states  of  the  place  over 
a  specified  time  interval  into  the  set  of  real  mrnbers. 

Another  way  to  state  definition  4.10  is  to  say 
that  a  performance  function  is  a  mapping  from  the  results  of  the 
execution  of  a  TEPN  model  into  a  real  number  which  represents  some 
standard  (or,  perhaps,  non-standard)  performance  metric  such  as 
throughput,  average  wait  time,  etc.  These  metrics  are  all  results 
of  some  "sunmarization"  operation  taking  into  account  every  state 
that  the  place  has  experienced  during  the  specified  time  interval. 

Definition  4.11  TEPN  Place  Execution  State 
The  TEPN  Place  Execution  State  is  a  function  of  time  and 
is  defined  as  a  vector  containing  the  values  of  all  state 
subattributes  of  the  Place  Clock,  the  Place  Active  Queue,  and 
the  Place  Enabled  Qjeue. 

By  combining  Definitions  4.10  and  4.11,  above,  we  see  that  the  domain 
of  each  place  performance  function  is  a  sequence  of  vectors  con¬ 
taining  the  values  of  state  subattributes  over  a  specified  time 
interval.  For  a  given  model  over  a  given  time  interval  this 
sequence  is  the  model's  state  history. 
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Definition  4.12  State  History 

The  state  history  of  a  TEW  place  is  the  sequence 

of  execution  state  vector  values  over  a  specified  time 

interval .  The  state  history  for  place  P  over  the  interval 

(tl,  t2)  is  designated  Sp(tl,t2). 

We  may  now  give  an  alternate  definition  for  a  performance  function. 

Definition  4.13  Place  Performance  Function  (alternate  definition) 
A  Place  Performance  Function  is  a  mapping  of  the  place 
state  history  into  the  set  of  real  nunbers.  In  functional 
notation, 

PPF  =  f(  Sp(tl,t2>  ) 

where  (tl, t2)  is  the  time  interval  over  which  the  performance 
is  being  measured. 

One  should  note  that  at  least  for  the  conceptual  definition 
the  internal  specifications  of  any  particular  performance  function 
are  to  be  avoided.  Part  of  the  significance  of  this  feature  in  the 
raw  definition  lies  in  the  fact  that  the  functions  are  defined 
as  part  of  the  construction  of  each  model. 

TEW  Token  Definition 

Like  the  TEW  places,  the  TEW  token  is  a  composite 
data  object.  Definition  4.14  defines  the  TEW  token;  the  two  token 


attributes  are  then  discussed  in  more  detail  below, 


Definition  4.14  TEPN  Token 

The  TEFN  token  is  a  composite  object  defined  by  the  following 

attributes: 

(1)  the  token  type;  and 

(2)  the  token  functional  attribute  set* 

Token  Type 

The  objective  of  the  token  type  is  to  provide  the  token 
with  an  identifier  that  can  be  used  to  control  the  token's  execution 
flow  path*  This  attribute  is  used  in  conjunction  with  the  transition 
firing  template  and  is  determined  at  token  generation  time  (during 
the  firing  of  a  transition)* 

Token  Functional  Attribute  Set  (FAS) 

At  token  generation  time,  each  token  is  built  to  include 
a  set  of  intrinsic  functions  which  return  integer  or  boolean  values* 
These  functions  return  values  which  are  used  by  the  place  token 
delay  time  function  to  determine  the  "service  time"  required  of  the 
token  upon  arrival  at  the  Place  Active  C^ieue  (PAQ)  *  Within  the 
TEEN's  conceptual  definition  the  exact  nature  of  these  functions  are 
not  defined,  since  they  are  arbitrary  in  nature  and  are  uniquely 
defined  for  each  token  created  and  cure  incorporated  within  the 
transition's  token  template*  Definition  4*15  does,  however, 
describe  the  concept  in  more  formal  terms. 
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Definition  4.15  Token  Function  Attribute  Set  (FAS) 

The  token  function  attribute  set  is  a  set  of  single-valued, 
integer  or  boolean  functions  of  the  form  (FNAME,  value),  where 
"FNAME"  is  the  function  name  and  "value"  is  the  current 
functional  integer  or  boolean  value. 

Marked  TEPN  Models 

A  TEEN  is  said  to  be  marked  when  one  or  more  of  the  TEPN 
places  belonging  to  the  network  have  one  or  more  resident  tokens. 
Similar  to  the  Petri  net,  the  marking  of  a  TEPN  determines  most  of 
the  state  attributes  of  a  given  network.  Unlike  the  Petri  net,  how¬ 
ever,  in  which  the  narking  is  simply  a  count  of  the  number  of  tokens 
at  each  place,  the  TEPN  marking  may  be  expressed  not  only  in  terms 
of  token  counts,  but  also  in  terms  of  specific  tokens  and  their 
current  attributes.  Because  of  this  potential  for  added  ccrplexity, 
this  Thesis  defines  two  markings,  the  internal  marking  and  the 
external  marking.  As  their  names  might  suggest,  the  criteria  used 
in  developing  the  definitions  of  each  of  these  marking  concepts  was 
the  "view"  of  the  internal  versus  external  "observers"  of  each 
place  and  of  the  network  as  a  whole. 

Definition  4.16  defines  the  external  marking  of  a  TEPN. 

4 

This  definition  is  equivalent  to  the  definition  of  a  Petri  net 


marking  for  a  Petri  net  that  contains  typed  tokens®.  Although 
the  information  required  to  derive  the  external  marking  exists 
as  a  subset  of  any  more  comprehensive  inventory  of  the  TEPN's 
resident  tokens,  a  separately  defined  external  marking  simplifies 
situations  where  more  complex  information  would  not  be  required. 
Furthermore,  it  is  important  to  recognize  that  the  external  narking 
is  the  narking  which  could  be  observed  via  a  "global"  view,  since 
no  place  or  token  (or  transition)  attributes  are  global  by 
definition. 

Definition  4.16  TEPN  External  Marking 
The  External  Marking  of  a  given  TEPN,  N,  is  a  K- vector, 
where  k  is  the  number  of  places  in  the  TEPN,  and  the  ith 
element  of  the  vector  is  an  m- vector  in  which  m  is  the 
integer  count  of  token  types  currently  defined  within  place 
P^,  a  unique  place  within  TEFN^  N,  and  the  jth  element  of  the 
vector  is  the  count  of  resident  tokens  of  token  type  TYj. 

The  internal  narking  is  described  by  the  sets  of  actual 
tokens  residing  at  each  place.  This  is  the  view  from  within  the 


6  Eteterson  [Peterson,  1979]  and  others  discuss  Petri  nets  with 
"colored",  or  typed  tokens,  as  a  manner  of  simplifying  Petri  nets. 

As  Peterson  points  out,  any  Petri  net  with  typed  tokens,  of  a  finite 
number  of  types,  can  be  shown  theretically  equivalent  to  some  Petri  net 
without  typed  tokens.  This  equivalence  does  not  necessarily  hold 
up  within  the  TEW  environment,  except  in  the  default  case  (in  which 
the  TEW  becomes  a  Petri  net). 
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place  itself.  Hie  internal  marking  includes  not  only  the  number 
and  types  of  tokens  within  each  place,  but  the  current  state  of 
each  token  and,  in  some  cases,  the  function  attribute  values  for 
specific  tokens  within  specified  places.  Definition  4.17  defines 
this  marking  concept.  Note  that  the  marking  is  characterized  by  sets, 
and  not  token  sequences  or  queues.  Hie  ordering  of  tokens  within 
each  place  queue  is  not  a  factor  in  the  marking  although  this  ordering 
is  important  to  the  place  state. 

Definition  4.17  TEPN  Internal  Marking 

Hie  Interned.  Marking  of  a  given  TEPN,  N,  is  a  (1  x  k)  vector, 
where  k  is  the  number  of  places  in  the  TEPN,  and  the  ith  element 
of  the  vector  is  a  partition  of  the  set  of  tokens  residing  with¬ 
in  place  P^,  of  TEPN  N,  expressed  as  an  ordered  four-tuple, 

M.  =  (TS  ,  TS  ,  TS  ,  TS  ) ,  where, 
i  w  a  eb  er 

TS  =  set  of  place  tokens  in  WAIT  state, 
w 

TSfl  =  set  of  place  tokens  in  ACTIVE  state, 

TS  .  *  set  of  place  tokens  in  ENABLED-BLOCKED  state,  and 

QD 

TS  ■  set  of  place  tokens  in  ENABLED-READY  state, 
er 

is  called  the  Local  Interned  Marking  for  place  P^. 

TEPN  Transition  Definition 

Like  its  Petri  net  counterpart,  the  TEPN  transition  is  a 
synchronization  primitive  which  controls  the  flow  of  tokens  across 
a  raw  model.  Similar  to  the  Petri  net  transition  (and  unlike  the 
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TEPN  place),  TEPN  transitions  neither  hold  tokens  nor  record 
the  passage  of  time.  All  actions  which  happen  at  a  transition  are 
considered  to  happen  instantaneously;  in  this  sense,  the  tran¬ 
sition  can  be  likened  to  a  switch  required  to  control  local  state 
changes.  Since  there  is  no  concept  of  action  or  token  storage  at 
the  transition,  the  transition  has  no  attributes  which  impact  the 
state  of  its  parent  net — all  transition  attributes  are  configuration 
attributes  whose  values  are  determined  as  part  of  the  model 
definition. 

The  TEFN  transition  is  formed  from  the  Petri  net  tran¬ 
sition  by  adding  two  attributes:  one  impacts  the  enabling  process, 
the  other  controls  the  creation  of  new  tokens  during  the 
transition  firing  process7.  The  first  attribute  is  the  transition 
firing  template.  The  firing  template  controls  the  transition 
enabling  process  by  selectively  filtering  input  tokens  and 
allowing  only  tokens  of  predetermined  types  to  enable  the  transition. 

The  second  attribute  is  called  the  transition  token 
template  set.  Since  TEFN  tokens  are  defined  with  attributes 
there  must  be  a  mechanism  for  building  new  tokens  with  the  attri¬ 
butes  requisite  to  correct  operation  of  the  model. 

7  The  TEFN  retains  the  basic  transition  firing  and  enabling  process 
of  the  Petri  net,  as  discussed  in  Chapter  3.  While  the  transition 
firing  template  and  token  templates  alter  some  of  the  specific 
conditions  under  which  transitions  may  become  enabled  and  create 
new  tokens,  the  basic  concepts  of  enabling  and  the  firing  remain 
intact. 
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Definition  4*18  defines  the  TEEN  transition;  each  of  the 
tho  attributes  are  then  described  and  formally  defined  fol lowing  the 
general  transition  definition* 

Definition  4*18  TEEN  Transition 

The  TEEN  transition  is  a  ccmposite  object  which  receives  tokens 
from  adjacent  input  place  nodes,  creates  new  tokens  for  trans¬ 
mission  to  the  output  places,  destroys  the  input  tokens,  and 
transmits  the  new  tokens  to  the  output  places  for  which  they 
were  created*  The  configuration  of  each  transition  is  defined 
by  the  following  two  attributes: 

(1)  TFTS,  a  set  of  transition  firing  templates;  and, 

(2)  TTTS,  a  set  of  transition  token  templates 

TEEN  Transition  Firing  Template 

In  a  E’etri  net,  a  transition  is  said  to  be  "enabled" 
whenever  there  is  a  token  residing  at  each  of  its,  input 
places*  Extending  the  TEEN  place  to  include  an  interned  token  delay 
mechanism  changes  the  definition  of  an  enabled  transition*  Rather 
than  simply  requiring  that  each  input  place  have  a  token,  a  TEEN 
transition  nay  only  be  enabled  by  tokens  that  have  been  "released" 
or  "enabled"  by  the  place  after  the  required  internal  wait  time* 

The  transition  firing  template  extends  the  transition  enabling 
conditions  a  step  further  by  allowing  selective  enabling  based  upon 
the  types  of  tokens  residing  at  the  transition  input  places.  More 


specifically,  a  transition  firing  template  acts  as  a  filter  that 
only  allows  tokens  of  prespecified  types  to  enable  the  transition. 
When  there  are  two  or  more  input  places,  the  firing  template  speci¬ 
fies  not  oily  the  token  types  that  may  enable  a  given  transition, 
but  the  allowable  combinations  of  input  token  types  as  well.  For 
exanple,  if  there  are  three  input  places  which  may  emit  tokens  of 
types  A,  B,  and  C,  the  enabling  patterns  might  be  (A, A, A),  (B,B,B), 
and  (C,C,C).  In  this  case,  the  transition  will  fire  only  when  there 
are  tokens  of  the  same  type  at  all  input  places.  Even  though  all 
three  types  are  "legal",  the  transition  would  not  be  enabled  by  any 
combination  not  specified  above  (e.g.,  (A,A,B),  (A,B,C),  etc.). 

The  primary  need  for  this  extension  arises  from  the 
difficulty  in  the  Petri  net  of  modeling  the  deterministic 
performance  of  systems  with  dynamically  chosen  multiple 
execution  paths.  For  exanple,  when  modeling  the  performance  of 
a  disk  subsystem,  the  modeling  objective  may  require  detailed 
information  concerning  the  performance  of  the  system  on  a  channel 
by  channel  and  disk  by  disk  basis.  If  the  workload  can  be  shown 
to  be  evenly  spread  across  all  of  the  subsystem  components,  this 
objective  does  not  present  serious  problems,  since  the  aggregate 
average  performance  will  reliably  model  the  performance  of 
individual  ocrponents.  However,  in  cases  vhere  certain  channels, 
controllers,  ^nd  disk  drives  are  more  heavily  utilized,  such  as 
a  system  in  which  the  system  software  storage  units  nay  be 
utilized  with  several  times  the  frequency  of  use  of  most  other 
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units,  the  model  must  allow  for  transactions  (possibly  represented 
by  tokens  in  this  case)  to  deterministically  specify  the 
execution  path,  a  feature  not  intrinsic  to  the  Petri  net  model. 

In  a  Petri  net,  when  there  are  multiple  paths  emanating  from  a 
place  there  is  no  way  of  controlling  which  path  will  be  taken. 

The  TEPN  transition  firing  tenplate  solves  this  dilemma  by 
allowing  only  prespecified  token  types  to  enable  the  transition. 

In  addition  to  the  extended  modeling  power  that  it 
affords  the  TEEN  model,  the  firing  template  often  reduces  the 
number  of  nodes  required  to  model  systems  by  allowing  several 
independent  paths  originating  in  a  ccrmon  place  node  to  be 
collapsed  into  one  path  with  multiple  firing  templates.  This 
advantage  is  demonstrated  by  the  model  presented  in  Chapter  VI. 

Definition  4.19  TEPN  Transition  Firing  Template 

A  firing  tenplate  of  transition  T  is  a  function  from  the 
set  of  local  internal  markings  of  all  places  in  I(T),  the  set  of 
input  places  to  transition  T,  into  the  boolean  set,  ENABLED,  NOT 
ENABLED  .  In  functional  terms, 

TFTjLD^-*  {enabled,  not  enabled], 

where,  LBh  is  the  current  local  internal  marking  of 

place  Pjf  the  jth  member  of  I(T). 
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TEFN  Transition  Token  Template 

Each  transition's  output  token  template  set  defines  the 
tokens  to  be  created  by  that  transition  during  a  firing  sequence. 
Because  TEPN  tokens  have  types  and  attributes,  and  because  these 
attributes  are  not  global,  each  transition  must  have  the  information 
necessary  to  build  tokens  with  the  "proper"  attributes.  The  mechanism 
for  doing  this  is  the  token  template,  which,  when  executed,  uses 
the  transition's  input  tokens  as  inputs  and  generates  a  single  token 
as  the  output.  The  set  including  one  token  terplate  for  each  output 
place  is  known  as  the  token  template  set. 

Conceptually,  an  output  token  terplate  is  a  function 
from  possible  sets  of  input  tokens  possible  output  tokens. 

There  are  a  few  attributes  of  the  token  terplate  which 
should  be  noted.  First  of  all,  while  the  input  token  set  is  used 
as  input  to  the  token  templates,  the  token  templates  are  completely 
independent  of  the  transition  firing  templates.  Secondly,  the 
concept  of  the  token  terplate  is  independent  of  the  particular 
attributes  of  the  tokens.  The  exact  attributes,  etc.,  are  dependent 
upon  the  system  being  modeled.  Definition  4.20,  below,  formally  defines 
the  transition  output  token  template. 

Definition  4.20  Transition  Token  Template 
A  Token  Terplate  is  a  function  from  the  set  of  sets  of 
possible  input  tokens  into  the  set  of  possible  output 
tokens.  More  specifically,  the  token  terplate  defines  the 
transformation  from  the  set  of  input  tokens  for  a  given 
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transition  to  a  single  token  to  be  created  during  the  tran¬ 
sition's  firing  sequence  and  sent  to  an  associated  output 
place.  In  mathematical  notation: 

TOKENi  =  TTTi  (TIS) 
where, 

TOKEN j  is  the  token  being  sent  to  place  , 

TTTj  is  the  token  template  associated  with  place  P^, 

TIS  is  the  sequence  of  tokens  which  enabled  the  transition 
(one  from  each  member  of  I(T) ), 

Pj  is  the  jth  place  in  the  set  0(T),  1«  j  £  /o(T)J , 

Execution  of  the  TEFN  Model 

Just  as  the  TEPN  marking  was  defined  in  terms  of  two 
observers,  so  the  model  execution  might  be  described. 

The  external  view  of  TEFN  execution  is  generally  identical 
to  that  for  the  Petri  net.  When  there  is  an  eligible  token  at  each 
transition  input  place  the  transition  "fires"  by  removing  the 
enabling  tokens  from  the  input  places  and  creating  new  tokens  for 
the  output  places. 

The  internal  view  of  the  execution  introduces  both  the 
firing  and  token  templates  within  the  transition  and  the  time  delay 
mechanisms  within  the  place.  Each  of  these  extensions  from  the 
Petri  net  have  been  individually  presented  earlier,  and  will  not  be 
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discussed  again  in  this  section.  It  is  important  to  recognize  that 
the  introduction  of  these  features  makes  both  net  performance 
analysis  and  TEFN  implementation  as  CPE  tools  more  oonplex  tasks. 
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CHAPTER  V 


THE  TIME-EXTENDED  PETRI  NET: 
IMPLEMENTATION  OF  THE  TEPN  MODELING  SYSTEM 


This  chapter  presents  machine  independent  module  and  function 
specifications  which  outline  an  implementation  of  the  TEPN  as  a  CPE 
tool. 

The  format  of  these  specifications  is  a  data-object  centered 
decomposition  using  the  methodology  proposed  by  D.  L.  Parnas  Parnas, 
1972  in  his  extensive  work  on  the  specification  of  software  systems. 
This  is  a  conceptual  design  stage  and  is  transportable  to  many 
potential  host  system  implementations . 

The  first  section  of  this  chapter  presents  the  objectives 
of  the  TEPN  modeling  system  and  relates  the  system  to  the  overall 
goals  of  this  Thesis.  The  second  section  overviews  the  TEPN  system 
design,  concepts  and  organization.  The  third  and  final  section  is  a 
set  of  highest  level  module  specifications. 

Objectives  of  the  TEPN  Modeling  System 

The  implementation  of  the  TEFN  has  two  major  goals.  The 
first,  and  possibly  most  important  goad  is  to  provide  an  effective 
test  bed  for  evaluating  TEPN  models  of  non- trivial  systems.  Because 
of  computational  complexity,  it  is  virtually  essential  to  use  auto- 
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nation  to  execute  a  TEPN  model  since  at  this  time  there  are  no 
known  techniques  for  analytically  "solving"  a  TEPN  model,  as  there 
are  for  solving  queueing  models. 

The  second  najor  objective  of  the  TEPN  system  imple¬ 
mentation  is  to  evaluate  the  TEPN's  cost-effectiveness  as  a  modeling 
tool.  There  are  several  areas  which  make  up  this  trait,  including, 

(a)  the  time  to  build  a  model, 

(b)  the  difficulty  of  validating  models, 

(c)  the  efficiency  of  the  actual  model  execution,  and 

(d)  the  usefulness  of  the  output. 

System  Design  Overview 

The  TEPN  Modeling  System  consists  of  two  subsystems.  The 
first,  subsystem  DEFINE. TEN,  provides  the  mechanism  for  the  user  to 
define  the  structure,  semantic,  and  performance  evaluation 
attributes  of  a  TEPN  model.  The  second  subsystem,  EXEC.TPN,  ini¬ 
tializes  and  executes  a  TEPN  model  according  to  user  specifications 
and  outputs  the  performance  statistics  resulting  from  the  model's 
execution. 

Each  of  these  subsystems  is  decomposed  into  Pamas  modules 
centered  upon  the  data  structure  and  other  najor  internal  design 


decisions. 


Subsystem  DEFINE. TEN 


The  purpose  of  this  subsystem  is  to  assist  the  user  in 
designing  accurate  TEFN  models  and  translating  these  designs  into 
internal  structures  that  can  be  efficiently  used  to  execute  the 
models.  Figure  5-1  illustrates  these  objectives  in  terms  of  inputs 
and  outputs  to  the  subsystem  as  a  whole.  The  inputs,  including 
the  TEPN  structure,  semantic  attributes,  and  performance  charac¬ 
teristics,  result  from  the  manual  network  design  process  and  are 
input  in  the  TEEN  Network  Definition  Language  (NDL).  The 
outputs  are  a  network  description  in  another  format  to  assist 
the  user  in  ongoing  model  development  and  the  TEFN  description 
file  for  the  TEPN  execution  subsystem. 


Figure  5-1  Subsystem  DEFINE. TEN 
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DEFINE. TPN  consists  of  three  nodules: 

(1)  MODULE  PARSER. NDL 

Each  DEFINE. TPN  system  is  partially  characterized 
by  a  user-interface  language  called  the  Net  Definition  Language (NDL ) . 
The  NDL  Parser  accepts  NDL  strings  and  translates  them  into  a  TEPN 
model  that  can  be  used  by  the  execution  subsystem. 

(2)  MODULE  BUILD. TPN 

This  nodule  consists  of  a  set  of  functions  vhich 
may  be  used  to  build  the  internal  structure  of  the  TEPN  model  as 
required  by  the  execution  system.  This  nodule  shares  data  structure 
with  TEPN,  PLACE,  and  TRANSITION  nodules  in  the  EXEC. TPN 
subsystem,  since  the  functions  must  have  knowledge  of  the  internal 
structure  of  these  TEPN  building  blocks  within  EXEC. TPN.  For 
this  reason,  BUILD. TPN  is  itself  partitioned  into  submodules, 
each  of  Which  only  deals  with  a  single  data  structure  (i.e. ,  only 
the  PLACE,  or  the  TRANSITION  —  not  both). 

(3)  MODULE  VERIFY. TPN 

This  nodule  nay  be  invoked  by  the  user  as  a  means 
of  verifying  that  the  final  TEFN  resulting  from  the  original  NDL 
definition  is  what  it  was  intended  to  be.  The  functions  in  this 
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The  subsystem  consists  of  six  modules,  each  of  vbich 
are  described  below: 

(1)  MODULE  INIT.TPN 

This  module  accepts  an  unmarked  TEPN  (probably 
from  Module  BUILD. TPN)  and  applies  an  initial  marking  to  it, 
thus  beginning  the  execution  cycle.  This  module  is  also  respon¬ 
sible  for  initializing  and  operating  any  "token  generators" 
required  to  simulate  workload  throughput.  The  designs  of  the 
initial  marking  format  and  the  token  generation  mechanisms  are 
localized  within  this  nodule. 

(2)  M3DULE  MASTER. TPN 

this  module  keeps  track  of  opcoming  events  in  the 
execution  of  models.  This  module  maintains  an  event  timing  (and 
"alarm")  system  which  allows  for  orderly  system  execution. 

(3)  MODULE  PLACE. TPN 

The  place  data  structure  design  is  embedded 
within  this  module,  vhich  consists  of  all  functions  used  to 
manipulate  the  place  structure  during  model  execution.  In 
addition  to  the  functions  required  to  execute  the  place,  this 
module  also  includes  the  set  of  functions  required  to  support 
the  BUILD. TFN  module  of  subsystem  DEFINE.NET  (although  for 


purposes  of  efficiency,  these  build  routines  cure  embedded  directly 
in  the  BUILD. TPN  module. 

(4)  MODULE  TRANSITION. TPN 

Similar  to  Module  PLACE. TPN,  the  TRANSITION. TPN 
module  defines  the  design  of  the  trainsition  data  structure  and 
supports  all  functions  required  to  execute  the  TEFN  transition, 
as  well  as  those  required  to  build  and  initialize  the  structures. 

(5)  MODULE  TOKEN. TPN 

The  token  is  dynamically  created  and  destroyed 
during  network  execution  and  this  module  localizes  all  functions 
related  to  those  processes.  In  particular,  this  module  consists 
of  the  functions  which  build  tokens  from  transition  token  templates 
as  wall  as  from  the  initial  marking  defined  by  Module  INIT.TPN. 

(6)  MODULE  TEFN. TPN 

This  module  maintains  the  internal  data  structure 
that  views  the  TEPN  model  as  a  whole,  rather  than  in  terms  of 
individual  places  or  transitions.  In  terms  of  the  original  TEPN 
definition  (definition  4.1,  of  Chapter  IV),  this  module  maintains  the 
TEFN  Input  and  Oitput  functions,  I(T  J  and  0(T  J ,  respectively. 

I 


I 


TEPN  System  Specifications 

The  remainder  of  this  chapter  presents  the  programming 
Design  specifications  for  the  TEFN  Modeling  System.  Three  of  the 
modules.  Modules  TOKEN. TPN,  TRANSITION. TPN,  and  PLACE. TPN,  form 
what  could  be  considered  the  "heart"  of  the  system  since  they  are 
the  direct  implementation  of  the  definitions  presented  in  Chapter 
four.  The  reader  will  notice  that  these  modules'  specifications 
closely  follow  their  formal  definitions  in  Chapter  IV. 

In  studying  these  specifications,  it  is  important  that 
the  reader  understand  their  purpose.  These  are  not  computer 
programs.  Nor,  for  that  matter,  do  they  define  specific 
algorithms  or  data  structure  designs.  Rather,  they  are  designed 
to  oomnunicate  the  functions  and  operations  that  are  part  of  each 
module  and  information  required  to  interface  with  each  module. 

The  format  for  the  specifications  is  uniform  throughout. 

For  each  module,  there  is  a  "header  section"  consisting  of  the 
module  name  and  a  general  description  of  the  modules  inputs  and  out¬ 
puts.  Each  header  section  is  then  followed  by  a  list  of  each  function 
defined  for  that  module.  In  the  case  of  the  basic  TEPN  data  objects, 
these  functions  include  not  only  actions  upon  the  object  but  the 
object's  attributes  as  well.  The  format  for  the  function  specifica¬ 
tions  is: 


Functions 


the  function  name  with  parameters  in 
parenthesis 

possible  values:  if  the  function  is  an  at¬ 
tribute  which  itself  takes  values,  the  value 
range  is  specified  here 

parameters:  the  names  and  data  types  of  any 
input  or  output  parameters 

effect:  the  external  effect  that  the  function 
will  have  upon  parameters  and  other  functions 
(including  calls  to  other  functions) 

initial  value:  if  the  function  can  take  on  a 
value  (i.e„ ,  if  the  "possible  values"  attribute 
is  other  than  "none"),  this  attribute  specifies 
what,  if  any,  initial  value  is  assumed. 


Module  Implementation  Specifications 

Module:  PARSER. NDL 

Module  Description:  Accepts  a  TERJ  defined  using  the  TER* 
Network  Definition  Language  (NDL)  and  translates  the  NDL 
strings  into  calls  to  functions  of  Module  BUILD.  TRJ.  These 
function  calls  cure  grouped  into  a  network  definition  "meta 
file"  which  may  either  be  saved  or  immediately  passed  to  the 
BUILD. TPN  module  for  processing. 

Impact  upon  other  modules:  Prepares  calls  to  BUILD. TPN 
Data  Structure  Unique  to  Module:  NDL  String 
Function  Description:  This  module  is  described  by  a  single, 
general  function  that  parses  NDL  strings  and  creates 
equivalent  function  calls. 

Function:  PARSE .NDL  (NET. NDL,  NET. ELD) 


possible  values:  none 
parameters:  file  NET. NDL;  NET.BLD 
effect:  no hr 
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Module:  PARSER. NDL 

Module  Description:  Accepts  a  TETO  defined  using  the  TEPN 
Network  Definition  Language  (NDL)  and  translates  the  NDL 
strings  into  calls  to  functions  of  Module  BUILD. TPN.  These 
function  calls  cure  grouped  into  a  network  definition  "meta¬ 
file"  which  nay  either  be  saved  or  irrmediately  passed  to  the 
BUILD. TPN  module  for  processing. 

Impact  upon  other  modules:  Prepares  calls  to  BUILD. TPN 
Data  Structure  Unique  to  Module:  NDL  String 
Function  Description:  This  module  is  described  by  a  single, 
general  function  that  parses  NDL  strings  and  creates 
equivalent  function  calls. 


Module:  BUILD.TPN 


Module  Description:  Accosts  a  set  of  function  oammands  prepared 
by  PARSER. NDL  and  builds  the  internal  TEPN  structure  which  is 
then  passed  on  to  subsystem  EXEC.TFN  system.  May  also  operate 
using  direct  command  file  (not  prepared  by  PARSER. NDL ) . 

Inpact  upon  other  modules:  none 

Data  Structure  Unique  the  Module:  TEPN  Data  Structure 
(PLACE,  TRANSITION,  TEPN) 

Function  Description:  These  functions  form  "virtual"  submodules, 
each  of  which  centers  upon  a  specific  data  structure  and 
is  conceptual  ly  "tied"  to  an  appropriate  module  in  subsystem 
EXEC.NET.  For  example,  each  place  is  built  using  functions 
(e.e.,  BLD.PLA  or  NEW.PLA)  within  BUILD.TPN  but  specially  designated 
with  a  .PLA  suffix,  lhese  functions  whare  "knowledge"  of 
the  internal  place  data  structure  with  module  PLACE. TFN  of 
subsystem  EXEC.NET. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  DEFINE. TPN  MODULE:  P^A 


FUNCTION:  NEW.  P'L*  (PNhHE ■ 

PO ! '  I ILE  VftLUEC:  FLficE-:i 
PmPmhETEPC  :  ^mum-etpini?  PNmmE 
EFFECT:  none 
INITIAL  VALUE:  none 

I'E  .'.FI  FT  ION:  Each  place  is  assigned  a  general  name  i  ,  the 
L'iER  ami.  am  internal  name  *  V  THE  EVETEM.  THEREFORE.  DnE 
OF  THE  FIRST  FUNCTIONS  OF  CREATING  A  NEN  PLACE  IS  TO  ASSIGN 


FUNCTION:  I.LI'.PlA  'P. TYPE*  TIN.  TOUT  • 

F'O-.IBLE  VALUEC :  none 

PAFAMETEF.:  flace-ii.  PS  flace-Tvfe  TYPE  I  tra*ct  TIN. TO" 
EFFECT:  CLOCK. TYPE  CP  -  =  tyre* 

call  ATiPPLA. NET ■ p. TIN. TOUT' 

B'-1 1 LI'S  the  place  internal  structure  '.without 
parameters ’ •  The  type  •  default  op  active  •  letermines 
the  TYPE  of  STRUCTURE  That  hill  EE  USES'. 


function:  e-liif-ao. pla  '.p.C'riic.TiiTM.BNii' 

POCCIELE  VALUES*  none 

PAF'ANETEF'Cs  flace-it  PS  pi'Iscifline  OIi ICC* 

integer  function  TIiTHS  integer  I; n£i 
EFFECT:  C'I>ISC . FAC1  <P>  «  G'l'ICCS 
TI'TM.  F'AC  <P>  «  TDTMS 
BOUNIi.  PflC>  CP>  »  BUI'S 


I'E  C  CPIPTION:  Initialises 


THE  ATTRI  J  UTES  OF  THE  F'LACE  flCTH'E  C'UEUE. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  DEFINE. TPN 


MODULE:  pla 


FUNCTION:  PLIiFEO.  PLA  <F  »C'I'I  JC  « Ini'  • 

PO-IIELE  VALUE::  none 

PAPAHETEP.:  FiftCE-it.  PS  fmscifline  C'l* ISC*  :wte5eb  I r<I 
EFFECT:  C'BISC.PEO  <F>  *  C'PI  CCS 
I:OUNl'.PEC"P>  =  PHI'S 

I'EICFIFTIDH:  Initialises  the  attributes  df  the  Place  Ena elei  Cue ue . 


FUNCTION:  PLI'PFF.PLA  <P.  F'PF  IE T  ■ 

F'OI'IPLE  VALUE::  none 

FAPAMETEF:i:  place- ii'  P5  fffeet  FPFIET 

EFFECT:  PFFS  <P<  =  PFFC  <F\>  ♦  FPFCET 


I'E.CF'IF'TION:  The  actual  flfice  performance  function  I'Efinitxdns 

APE  IDTM  implementation  AN!'  USER  I'EPENt'ENT.  This  FUNCTION  ASSUME! 
that  THE  F'PF  NAMES  IN  PPFSET  HA*  ‘E  SEEN  E.EFINEI'  EITHER  Ii  THE 
IMPLEMENTATION  Sr  STEM  <SU'S'5ESTEI'  FOB  MOST  COMMON  FUNCTIONS'  OP 
THE  USEP. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  DEFINE. TPN 


MODULE:  BUILD 


FUNCTIONS  NEW.TFh  • THhmE • 

PQ-SlfcLE  VALUES*  TRAt4£  I  T  3  Dr j”  1 1' 
FhF'HMETEF  I  5  #iN'.'t1“5TP*!N5  THAME 

EFFECTS  none 
INITIAL  VALUES  no»<e 


t<E  :CF  IF  T1  QMS  *SSI*UT 
TPhUE I t i oh  name* 


Af4  INT6RN*L  REFERENCE  NAME  TO  THE  U:EP"'?  1  l.’EN 


FUNCTION:  fcLI'.TPA  '-T *  PIN*  POUT  > 

PDSSIPLE  VALUES!  none 

FhFhmeTEF: :  TRSHriTiBN-ir  t:  fl^-et  FIN.  FDUT! 

EFFECT!  call  ftDIiTFFl.NET  <T.  FIN.  FDUT  > 


DEI  OF  I  FT  I  ON:  F'JJUI'f  THE  INITIAL  Z  UTEPNftt  fTF'JCH.OE  FDR  TR^-mOX  1 
*’JI'  CF.L.US  FUNCTION  to  INSERT  TFftNFITIDN  INTO  THE  NET  STRUCTURE .  V 


FUNCTION:  BLDTT.TFft  <T«TT ' 

fo::ifle  value::  none 

FAFftr-IETEF" :  trams zt ion- it.  T!  toktehf-ii.  TT! 

EFFECT!  TT.:  <T>  =  TTC  <T>  +  TT 


DE'CFIFTIDN:  DuilI'S 


the  TO. en  TEMFLATE  AS  RTTRISUTE  of  TRANSITION  T 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  DEFINE. TPN 


MODULE:  BUILD 


FUNCTION:  fcL&FT.TFA  <  T «  T  F  T  • 

FD'UILE  VALUE::  nohe 

FftFAMETEF '  :  tpp»-jf  :  non- j*  T:  p  j retemf -i r  TFT 
EFFECT:  TFT:  •  T  •  =  TFT  1  •  T  >  ♦  TFT 


I'EiCF'lF'TlDN:  Boiurr  the  TPFmEiTjoti  rt»iN?  TEMfuftTE  ftj  sttpiiij-'e 

OF  TPFinflTJON  T. 
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Module:  VERIFY. TPN 

Module  Description:  This  module  allows  the  user  to  verify  that 
the  TEW  structure  built  is  the  same  as  that  which  was  actually 
intended  by  the  user.  The  module  allows  the  user  to  examine 
either  a  single  node  within  the  net  or  the  entire  net. 

Impact  upon  other  Modules:  Calls  functions  from  other  modules. 
Data  Structure  unique  to  Module:  none 
Function  Description: 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  DEFINE. TPN 


MODULE:  verify 


FUNCTION:  VERIFY. FLA •FNAME 1 

F'DI'IPLE  VALUE!:  ndue 
FAFAMETEF! :  ELftCE-MSnE  PHAI'.E 

EFFECT:  none 


ICCCF 1FTJQN:  Petupne  cohfreheneh/e  hscriftion  of  a  ifecifiec>  flrce. 


FUNC  TIONS  VEF  I FY.  TRA  •  TNAME  ' 

F'O!  !  I FLE  VALUE  I :  none 

F'AF  AMETEF  l :  TRhmjitiom-name  THAME 

EFFECT:  none 


I'EICFIFTIDM: 


FeTLIPN*  COHF  PEHEN:  1 t‘£  t'EfCPIFTID'J  DF 


ff  ECIF1EI' 


TPPHj I T 1 O 


FUNCTION:  VEF IFY.NET 'METHANE • 

FOCriPLE  value::  non 
PAPAMETERSs  netnpme  NETNAME 
EFFECT:  none 


lEICRIRTIQN:  Retupne  TEPN  stpuctupal  cefinitidh 


Subsystem  EXEC.NET 


Module  Implementation  Specifications 


List  of  Modules 


Module 


Description 


INIT.TPN 


Initializes  TEPN  for  execution 


MASTER. TPN 


Master  control  for  TEPN  execution 


PLACE. TPN 


Place  data  structure 


TRANSITION . TPN 


Transition  data  structure 


TOKEN. TPN 


Token  data  structure 


TEPN. TPN 


General  TEPN  attributes  (external) 


Module:  INIT.TPN 


Module  Description:  Module  initializes  TEPN  narking  and  other 
functions  required  prior  to  the  execution  of  a  TEFN. 

Impact  upon  other  Modules:  Calls  functions  within  other 
modules. 

Data  Structure  Unique  to  Module:  Net  initialization  format. 
Function  Description: 


’3 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET  MODULE:  INIT.TPN 

FUNCTION:  MAFt  FLH. INI iFNAHE  «  TOt  ■ 

POSSIBLE  VALUES  s  NOME 

F'AF  AnETEF'S :  fusce-nshe  PNAME?  tofen-ii?  TOt 
EFFECT:  F=F LmC Eli'  «PUAHE  • 

call.  TDl  APF'.PLA  *F?T0t  ' 


I'ESCF  1PTIOM:  Insepts  am  initial  td*en  imtd  a  place 


FUNCTION:  K'DTOF.INI  <TO»  -* ATTF SET • 

POSSIBLE  VALUES'*  none 

PAPAMETEP S:  token  name  TOt  •  top  Em  attpieute 

eet  ATTF  SET 

EFFECT:  none 


DESCRIPTION*  BtuiLts  am  initial  etate  top en  with 
USER  supplies  attribute  set. 


FUNCTION*  PUN. INI  iPLIST- 

POSSIBLE  VALUES:  none 

PAFAMETEPS'S  pun  parameter  list  FlIST 

EFFECT:  Initialize  all  pun  fpirametep- 


I'ESCPI F'TIOM:  This  function  will  estailish  all  the  mechanisms  PEruiPES 

tv  rum  parameters.  Since  these  ape  implementation  cmafactefistics  pins 
I'O  NOT  AFFECT  THE  TEF'N?  NO  SESlStl  IS  PPESENTEI'  IN  THIS  THESIS  FOP 
parameter  operation.  As  a  minimum?  the  mdi'El  halt  cpitepiom  is 
HEESES  AS  A  PAPAMETEP. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET  MODULE:  MASTER. TPN 


FUNCTION*  FEVSCH.NAS  <P»  TIME* 

possible  values*  none 

PAPAMETEFSs  flaced-id  FS 
INTE5EP  TIME. 

EFFECTS  hone 


I'E SCF  IFTIOns  Thi e  function  pucuce  a  pl*ti.we  E'Ent*  the  tpmii-fep  dp  a 
fPECIFlEI'  TO*  EN  in  A  ffECIf  1EI'  PLACE  FROM  THE  PAC*  TO  THE  PEC'  AT  am 
1  AlPEAI1  i  IETEPiUuEI'  TIME. 


FUNCTION*  FEVFEM.MAS  <F'»  time* 

POSSIBLE  VALUES*  none 

PhFAMETEPS:  place- i r*  F<  intec-ep  time 

EFFECT*  home 


I'ESCF'IFTIDMS  I'eletes  an  Bcent  fpdm  the  fl'T'.'PE  ei-'Ent  Pueue . 


FUNCTIONS  HKTEV.MAS 

POSSIBLE  VALUES*  none 
PARAMETERS*  none 

EFFECT*  If  malt  ffpaaeteps  met  the  malt  ELSE 
P=F.  EVT  <  CONEKT  <FEVC*  *  * 
call  PLAENA  CP:* 


DESCRIPTIONS  Identifies  the  ne*t  ei*eht  in  the  futlipe  h'Ents  rcc-'E  and 
REMOVES  THAT  PUEUE  ENTPt.  PLAENA  IE  CALLED  TO  EUAILE  THE  TO*  EN  AT  THE 
PAO  IN  THE  AFFROFPIATE  FLACE.  THIS  TPISC-EPr  AN  v  NEllLV  ENAElED 
TRANSITIONS  AND  PEEL'LT  X N5  CHANGES  TO  THE  TEPN  STATE. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET 


MODULE:  PLACE . TPN 


FUMCTID:  PLACE  1 1'  'PNAME 1 

F'OSSIBLE  VALUES:  plpce-H'.  ■ 

F'AF'AMETEF'S:  DHwsTfiNi  PNAME 

EFFECT:  none 

INI  URL  VhL UE :  none 

PET  UBIlj  THE  INTEPNHL  FuPCE-II-  WHEN 
C-Il'EN  THE  UEEP  t'Er)  HE  t  FUnCE  Nr.M£  . 


BE  SC PI FT  I  DM: 


FUHCT I  ON :  BOON  I* .  F'LR  <P  > 

F'D SSI BLE  VALUES:  nohefo-itii>e  inte«ep; 
F'AF'AMETEF'S :  pl.ace-XZ>  F 
EFFECT:  none 

INITIRL  VRLOE:  HIGHVAlUES 
BESCPIPTION:  Sum  of  the  F'EC1  f>nv  FAC1  *our.irs. 


FUNCTION:  F'LRRCT.F'Cfi  <P»TO*..> 

POSSIBLE  VALUES:  home 

PARAMETERS*  place- ie>  P5  token- ix.  TDt 

EFFECT:  cfill  PROAUIi. FLA  <P«TOt 


I'E-CP IF'TION:  "Acth/ates"  place  upon  appiksl  of  a  token  fpdm 

PN  input  TPAN5ITION. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 
SUBSYSTEM:  EXEC.NET  MODULE:  PLACE. TPN 


FUNCTION:  ©DISC. PEC1  -P  ■ 

POSSIBLE  VALUES!  PUEUE1NJ  1'ISCI^LINEI 
PAPAMETEPS*  place-ii-  F 
EFFECT:  none 

INITIAL  VALUE:  infinite  hfoceieds 

DESCPIPT1DN:  The  Place  EuftiLtr  ©l'eve  is  isfinei  i  v  onl  . 

TWO  FUNCTION-  SINCE  THEPE  IS  NO  IWTEPHSl  I-EL.Fi  .  FUNCTION 
FiFFLIEI'  TO  TOk  ENS  ENTEF1NC-  THE  PEC'. 

The  INITIAL.  PL'EL'EIN.;  MSCIFLIHE  IS  "infinite  fpdcessdp' 
WHICH  ALLOWS  ALL  TOKENS  THAT  HAi-e  COMFLETEI'  the  internal 
I'ELA,  AT  THE  PAC1  TO  IE  IMMEt’IATELT  A-AILAILE  TO  ENAS  LE 
AN  I-  FI  PE  TRANSITIONS. 

FUNCTION:  BOUND.  PEC  >  F  > 

POSSIBLE  VALUE  I:  positive  intec-eb? 
PAPANETEPI:  place—  i  s*  P 
EFFECT:  none 

INITIAL  VALUE:  HUSH VALUE 

DESCRIPTION:  C'ueue  sown r-  on  the  PEC'. 


FUNCTION  SICE. PEC  <F,' 

POSSIBLE  VALUES:  positive  inteseps 
PAFAMETEF S :  PLACE- 1 r-  P 
EFFECT:  none 

INITIAL  VALUE:  0 

DESCRIPTION:  Sise  of  the  F'ECn  the  numiep  of  tokens  there. 


FUNCTION:  SIZE. PAC  <F ■ 

POSSIBLE  VALUES:  pdsitil'e  integers 
PAF'AMETEF’S:  place- I r  P 
EFFECT:  none 
INITIAL  VALUE:  0 


DESCRIPTION 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET 


MODULE:  PLACE. TPN 


FUNC  T I  DM:  I  NTMhO  .  F'Lh  >  F‘  • 

P'DI  tlt-LE  VALUED  set  op  to»-  ems 
PAF  AMETEF'i  8  p  lpce*  i  r  E 
EXPECT?  NONE 
INITIAL  VALUE*  null  set 

DESCRIPTION:  Returns  the  internal  mwm nc-<  the  eet  df  sll 

TO*  IN*  JN  F.  FLACE. 


FUNCTION:  FftC'ftPP.PLft  <F> TO*  .. 

F  O:  i  1 1  LE  VF.LIJE  I  :  none 

FhFhMETEF  ;  :  flf.ce-: r-  PS  token— n*  TD» 

EFFECT:  iHTMftPt  <p  •  *  IHTMftPt  <F>  t  TD> 

if  TO*  «  C'MEXT . F'Lft 1  PftC*. F' >  THEN 
Time  =  TPTM.  F'Lft 
cf,ll  FEVSC  H .  (1h  ‘  CP .  T  I  HE  ■  > 

INITIAL  VALUE:  n  f. 

PE  SC  FI  FT  I  DM:  ftr.r.s  incoming  to*eh«  TO*  •  to  the  PRO  of  flf.ce  P. 

ImTEPnFlU  I  '  THE  TOt  EN  WILL  IE  IN5ERTEE  F.CCOPMN.5 
TO  THE  F'ftO  5  FUEUElN'S  I'lECIFLINE. 


FUNCTION I  ONE XT. PL ft  cO»P> 

F'OI  SIDLE  VALUES :  token 
PAPAHETEFS:  fueue  C* 5  f-lfice-ie.  F 
EFFECT:  none 
JMITIftL  VALUE  s  null 

DESCRIPTION*  Returns  the  "next"  token*  or  the  token  "on  tdf " 

SCHEDULE*  TO  LEF,.'E  THE  FUEUE.  If  THERE  15  MORE  THAN  DNE  Pl.-’F.  I LAJLE 
TOKEN  THE  FUNCTION  WILL  RETURN  ONE  CHD5EN  F.T  RF.NE.OM. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 
SUBSYSTEM:  EXEC.NET  MODULE:  PLACE. TPN 


FUNCTIONS  TDTM.PLA  <P»TO*  • 

FOS SIDLE  VALUE. :  intesep 
PAPAMETEPS*  FLfiCE-Jf  P?  TOfEH-II'  TQI 
EFFECT:  hduE 

INITIAL  VALUE :  0 

DESCRIPTION:  Executes  the  flsce  TDTll  du  the  ihcomuw  to.  eh. 

This  FUNCTION  If  t'EFINEI'  Ii  the  USER  ftT  NET 
rEFINTJON  TIME  ANt'  MA I  USE  THE  ATR1IUTES  OF  THE 
TO.  EN  FAS  Ik  JTf  COMPUTATION. 


FUNCTION:  PLASEND.  F'LA  <TOi  TYSET*  T  • 

POSSIBLE  VALUES*  none 

PAPANETEP ■; :  set  of  to.en-tyfee  TO*  TYSET* 
TFNHflTION  T 

EFFECT:  ENATOt . PL A • TDt TYPE ■ 

call  PEC'DEL.  PLh  .p.TDI  • 
call  ADI' INTO*  .  TPA  (T.TDt  ' 

INITIAL  VALUE:  n  a 

DESCRIPTION:  TP155EFf  PLACE  TO  "SEMI''  A  TO.  EN  DF  ONE  DF  THE 

TYPES  IN  TO*  TYPE  TO  TPANSITJDN  T  AS  FART  DF  A 
TRANSITION  FIRIN'?. 


FUNC  T I  ON:  PAC'D  I  SC  .  PLA  •  p :•  I 

POSSIBLE  VALUES:  fueue  mscifline 
PAPAMETEPS*  place-H'  P 
EFFECT:  none 

INITIAL  VALUE:  user  input 


DESCRIPTION:  User  specifies  each  PAO  fueue  mscifline. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET  MODULE:  PLACE. TPN 


FUNCTION:  FAC'ENIn  PLA ■  P  • 

FOIClfcLE  VALUE  : :  1WTE5EB 
PAFAMETEF  I :  fl«ice-iE’  F1 
EFFECT:  none 

INITIAL  VALUE  5  HIGH  VALUE 

I'E  I C F'  1  FT  I  OHt  C'uEuE  EO'.'ui  lone  for  each  FAC1’. 


FUNCTION:  TIiTMIiEF.FLA'F. 

FOI "  1  PlE  VALUES:  buntjon  iiefinitidnx 
FAFhIIETEF:  :  flb.ce- it'  F 
EFFECT:  none 

INITIAL  VALUE:  zepd  function 

I’ESCPIPTION:  the  i  b.lue  returnei.  is  a  user  t'EFiNEt'  function 

WHICH  USES  THE  FLIHCTIONBL  BiTTBIIUTE  SET  B.S  I  STS  B  BPftnETEPX 
BiNt'  RETURNS  THE  TO.  EM  I'ELA  .  TIME. 


FUNCTION:  ENATOt  .F'LA'TOt  TYPE’ 

F’DSSIfcLE  VAlUES:  a  td.  en-iii<  null 
FAFAMETEF;:  token  tyfe  TQt  TYFE 

EFFECT:  none 

INITIAL  VALUE:  null 

I'ESCFIFTION:  Searches  the  PEP.  If  it  FiNfs  an  enbilei1 

And  RE  At’  .  TO’  EM  MPTMCIN5  THE  TYFE  BASSEI"  IT  BASSES 
THAT  TOKEN—  It*. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET  MODULE:  PLACE. TPN 


FUNCTION:  T 1  C>  TIM.F'LA-F:- 

fo::i*le  value::  none 

effect:  T1ME-F'  *  TIME*P*  -1 

F  ftBftMETEBI !  F  lACE-11'  P 

INITIAL  VALUE:  n  a 

ICICFIPTION:  PeFINES  ft  C'E  CP£«:IN5  F  L  ACE  CLOCH  FUNCTION. 


FUNCTION:  EFTOI  .F'LA'TD*  .  F  • 

Foe ; iele  value::  tfue  op  fal:e 

FAF  AMETEF' C  :  token-ii,  TD(  *FuftCE-li'  F 
EFFECT:  none 

INITIAL  VALUE:  FAlIE 

I'E :c F'  IF  T  ION:  Returns  TFUE  if  TOl  is  enailei  ANf  peac>  i  in 
the  c'EC'. 


FUNC TION:  F'LAF I FE . F LA  •  F' > 

F'O'CIPLE  VALUE":  none 
F-APAMETEF  " :  flace-ii.  F 

EFFECT:  fop  each  memieo  T  df  F'OuT  CET .  TFN 1  F  • 

CALL  TFAFIFE.TFA'T • 

PECCF'IF'TIDN:  Fop  fill  arcs  out  from  f<  place  to  a  transitions 

CALL  A  function  which  fipes  that  TRANSITION  if  it  IS  non 
ENAS  LEI'. 


FUNCTION.-  FEC'AI'P.  FLA  'F  .  TO>  • 

FOICIPLE  VALUE":  none 

FAP  AmeTEF  "  :  FLACE-ir  F.  tohen-is  TD* 

EFFECT:  IF  EPTOt  ,  F'LA  ■  TD*  >F' 

CALL  F'LAF  I  F'E  .  F  LA  •  F'  :• 

PECCF'IF'TIDN:  firt'S  a  tdhem  to  the  F'EC'  ani>  ufi-ates  the  poeue. 
If  there  is  an,  change  to  the  set  of  fhailes  actus  tokens 
functions  are  callei  which  chech  all  O'jtsdihs  arcs  from 
this  FLACE  ANt'  FIRE  ANY  NEHLY  ENAILEI'  TRANS  I T I ONS . 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET  MODULE:  PLACE. TPN 


FUNCTION:  OSICE.PLA'O.Fv 

POSSIBLE  VALUES:  fdjitI'E  intesea 
PAPAMETEFS  :  LOCAL  PUEUE  I  !■  0*  FLACE-II'  F 
EFFECT:  moke 

INITIAL  VALUE:  noue 

I'ESCPIPTION:  F'etlwns  the  sice  of  a  pueue. 


FUNC  T I  ON:  PAOPEL.  Flh  •  P  . 

PO :  :  1 t LE  VALUE  : :  none 
PAF AHETEPS :  fi_ace- t  r  P 
EFFECT:  TO*  =  ONE:  :T .  PlA  •  PAO*  F  • 

CALL  PEOAM'.PlA  *F*  TOt  • 

IF  C'SIlE.FLA*PAO*P'>  o 
TIME  =  TPTM.  F  lA  '  P»  TDI  • 

call  fevs c h . ma : *f . time- 
initial  VALUE:  N  A 

PE : C FTPTION:  Tbahjfebs  ONE:  IT  <PAO*P*  to  the  PEC*  *  .•  calums 
FEC'AI I'.  Them  the  PAO  is  pe'-ienei-  ami-  ft  function  callei- 
TO  I N  a  EAT  AN  ENTA  ,  IN  THE  FEVO  IF  THE  F'EC'  IE  Id  EMF  T  I  . 


FUNCTION:  F'LAENA.  PLA  *P  • 

PO: ; ItLE  VALUES!  NOME 
PAPAMETEFS:  FLACE-:r  P 

EFFECT:  CALL  F'AOI'EL.PLA  •  F  > 

INITIAL  VALUE:  N  A 

PESCPIPTION:  fpANjFEF;  THE  NE  '  T  TOF'EN  ON  THE  PAO  TO  THE  PEC1* 

THEN  CALL.S  FUNCTIONS  WHICH  L*LI'ATE  THE  PAO  AN!  F'EC1  AHI'  MftF  E 
AESULTfttJT  ETftTE  CHANGES  TO  THE  TEF'N. 
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Module:  TRANSITION. TFN 


Module  Description:  Contains  all  functions  necessary  to  "execute 
the  TRANSITION  data  structure. 

Impact  Upon  Other  Modules:  None 

Data  Structure  Unique  to  Module:  TRANSITION 


Function  Description: 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET  MODULE:  TRANSITION. TPN 


FUNCTION*  TPAENA.  TFA  »T *  TFT  • 

F'QI  i  IILE  VALUE;*  * dolCam  CTPUE •  FALt  EJ 
PAPAMETEF'S  *  TMufiTioii-is  T»  firing  templets  TFT 
EFFECT*  hd'ie 
INITIAL  VALUE*  FALSE 

BESCPIPTIDN*  Checks  all  of  transition  T  infut  places  against 

TRANSITION  FIP1N5  TEHFLftTCS. 

Ip  each  place  HAS  THE  TOKEN  REFUIAEt*  TO  ENA* LE  THE  TRANSITION* 

THE  FUNCTION  RETURNS  THE  '  TFUE  ANt"  ALSO  RETURNS  THE  EnAIlIK'; 

FIRIN'?  TEMPLATE*  TFT*  FOR  USE  IN  THE  FIRING  SEQUENCE  'MOTE*  This 

FIRING  MUST  IS  AN  INI'l  I '1  S  1 1 LE  OPERATION. 

FUNCT I  DM*  TF'AF  I F: .  TFA  •  T> 

POSSIBLE  VALUES*  none 
PAPAMETEF'S*  trans ition-ii.  T 
EFFECT*  IF  TPAENA ■ T *  TFT  *  THEM 

CAlL  F’LASENI'.  FLA  •  TFT*  T*  INTO1  S  E T  > 

CALL  TTEX.EC  <T *  INTDt  SET  - 


BE5CPIPTIDN*  Each  time  a  token  enters  the  ''enrileI'-peM'.  " 

STATE*  this  FUNCTION  IS  CALLEI'  * i  THE  PLACE.  IF  A  CALL  TO 
TF’AENw  RETURNS  'TFUE  »  THE  TRANSITION  IS  ENAS  LEI-  AN  I*  TO*  ENS 
ARE  COLLECTEI'  FROM  THE  PLACES  ANI'  PASSE!'  AS  A  SET  TD  TTE  IEC  . 


FUNCTION*  AflDlNTOt .TPA'T.TDt  > 

POSSIBLE  VALUES*  nds 

FAFAMETEFS*  transition  it.  T*  token- in  TDt 
EFFECTS  INTDt  SET  -  T  '  =  INTO*  SET  >'.T >  *  TDt 
INITIAL  VALUE*  NA 

BESCFIPTIDN*  Art'S  a  token  to  the  eni.  of  the  set  dp  tokens 

COLLECTEI'  FROM  THE  FLACES. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET 


MODULE:  TRANSITION. TPN 


FUNCTIONS  TTEXEC  .  TF'A  -T •  INTO*  SET) 

POSSIBLE  VALUES:  none 

PHPAHETEPSi  tppnsition-ii-  T>t»en  fet  INTOi  SET 
EFFECT:  fop  each  TT  in  TTS-T- 

TD*  =ME*->TD* 

FAS -TO*  - «TT  CINTD*  SET  - 

TO*  T  VF'E  *  TO*  ;•  =  TT  -  INTO*  SET- 

F'=TTF'LA.  TFA-TT ■ 

CALL  TF'AIEUI'-TD*  *F  ' 

INITIAL  VALUE:  NR 

I'EICF  IFTIOH:  " E  ‘Ecutef "  the  tba-ifi t son  token  template  i. 

CPEnTlNS  THE  NEW  TOKEN  BHt'  CPLLS  P  FUNCTION  TD  FEHI'  THr 
TOKEN  TO  THE  PFPPQPPIPTE  FLPCE. 

FUNCTION:  TTS.TFA-t- 

POSSIBLE  VALUES:  set  of  token  temflptes 
PARAMETERS:  tppnsition  ir  T 

EFFECT:  none 

INITIAL  VALUE:  null  set 

I'ESCF'IFTIDN:  Petupns  set  of  token  temflptes. 


FUNCTION:  TTFLA. TFA ■  TT> 

POSSIBLE  VALUES:  plpce-id 
PAPANETEPS'8  TDK  EN-TEMFLPTE  II-  TT 
EFFECT:  none 

INITIAL  VALUE:  none 

I'ESCF  IF'TIQN:  Petupns  the  plpce-ii-  td  which  p  tok  en  must  ie  sent. 


S 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET  MODULE:  TRANSITION. TPN 


FUNCTIONS  TFACENIi.TFA'TOt  •  F  > 

F'DCC  I FLE  Vhl  UE ' :  none 

FAFAMETEF'C :  TDfEw-lt  TOt  «  flaceiI'  F 

EFFEC  T:  CALL  FLAAC  T .  FLA  ■  F  .  TD-  • 

INITIAL  VALUES  N  a 

I'ECCF'lF'TIONs  The  "cdiimumicstion  intepfhce'  ietmeeu  TPsunuoN 
T  F>NI'  f'LftCE  F  »  "SEMI'S”  NEIILi  CBEATEt'  TO'  EU:  TO  FLPCE  F  . 


FUNCTIONS  TFT3 .  TF'A  •  T  • 

F'OCC  I BLE  VALUEi  s  set  fo  tban-itid'i  pipin'?  temflpte? 

F'AF'AMETEF'C  8  TPFiNSITlON  T 

EFFECT:  home 

INITIAL  VALUES  null  set 

I'E CCFI F'T ION:  Set  op  tppnsition  pipin'?  temflptes. 


i 


Module:  1EPN.TJN 


Module  Description:  Localizes  functions  concerned 
with  the  overall  TEHJ  structure  and  which  require 
manipulation  of  inter-nodal  arcs. 

Impact  Upon  Other  Modules:  none 
Data  Structures  Unique  to  Module:  TEFN 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET 


MODULE:  TEPN.TPN 


FUNCTION:  lNTMAFt  .  TF'N  •  TEF'N  ■ 

PDSSlfcLE  VALUES:  TEF'N  intephal  map>  in.; 
PARAMETER' S :  tefn-ip  TEF'N 
EFFECT:  none 

INITIAL  VALUE :  none 


HE SC FI FT ION: 


FUNCTION:  EXTMAP*. .  TF'N  '  TEF'N  • 

F'OCSU'LE  VALUER:  TEF'N  e  tephAl  map*  ins 
F'AFAHETEF  I :  tefn-  j  !•  TEF'N 
EFFECT:  none 

INITIAL  VALUE:  N  A 

I'ESCPIPTION:  Returns  the  cuppeht  EXTERNAL  mapun*  Dp  the  TEF'N. 
This  function  ma.  hlso  *e  uset'  ht  the  eni>  op  the  pun  to  output 

The  PI NHL  MAPI  JH5. 


FUNC  T I  DM :  F'EF'F  S  T  AT .  TF'N  •  TEF'N  • 

F'OCCIELE  VALUES:  none 
PARAMETERS:  tefn-ij,  TERN 

EFFECT:  nonI' 

INITIAL  VALUE:  HA 

1‘ESCF'IF'TIOn:  Returns  the  cuppent  op  final  feppopmance  etatietice 

fpo'i  p  TEF'N  pun. 


FUNCTION:  TINFH.TF'N  •  T  ' 

POSSIBLE  VALUES*  set  op  flace- 
PARAMETER'S*  tpane  i t  i on- i  r.  T 
EFFECT:  none 

INITIAL  VALUE:  null  SET 


I'ES'CFIFTION:  CoRPETPONt'S  to  the  tpaneitidh  infut  function 

I'EFINCt'  I,  THE  IA5IC  TEF'N  SEFINITION  PNI'  PETUPNI  THE  SET  OF 
INPUT  FLACEI  TO  TPANEITIDH  T. 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 


SUBSYSTEM:  EXEC.NET  MODULE:  TEPN.TPN 


FUNCTION!  TDUTFN.  TF'N  •  T> 

POSSIBLE  VALUES*  function  ffom  TEPN  tffinsitioni 
TO  f  E  T  5  OF  TEF'M  FLftCEi 
PARAMETERS:  twiijitioh-i*  T 

EFFECT!  NULL  SET 
INITIAL  VALUE: 

DESCRIPTION!  Connensfonis  td  the  tfhnjitiom  function  pefinep 
I  ,,’tmE  IA.MC  TEF-N  I.EFIN1TIDN  FiNP  FETUNN:  the  SET  of  OUTFUTr 
FLFCE?  FROM  WNSJTION  T . 


FUNCTION!  F'DUT  SET.  TF'N  •  P  • 

POSSIBLE  VALUE S*  set  of  tfnnsitidne 
PAPAMETEP:*  FLAce-ir  P 
EFFECT!  none 
INITIAL  VALUE!  null 

DESCRIPTION:  Gii'eh  fi  flack-ii*’  betufne  the  set  of  fill  tiffuj- ition 

TD  WHICH  OUTWAFP  ARCS  FROM  THAT  FLftCE  CONNECT. 


FUNCTION!  FLA  SET .  TF'N  'TEFN' 

FOi i IDLE  VALUES!  set  of  flacks 
PARAMETERS*  TfFN-ii'  TEFN 
EFFECT!  NOME 
INITIAL  VALUE:  null  set 


DESCRIPTION* 


FUNC  T I  ON  i  TPAS  ET .  TF'N  'TEPN  • 

POSSIBLE  VALUES:  set  of  transitions 
PAPAMETEP Si  tkfn-IS  TEFN 
EFFECTS  home 
INITIAL  VALUE:  null  set 


DESCRIPTION: 
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Module:  TOKEN. TFN 

Module  Description:  Contains  all  functions  necessary  to  build 
and  delete  tokens. 

Impact  Upon  Other  Modules:  None 
Data  Structures  Unique  to  Module:  TOKEN 
Function  Description: 


i 


TIME-EXTENDED  PETRI  NET  MODEL  IMPLEMENTATION  SPECIFICATIONS 
SUBSYSTEM:  EXEC.NET  MODULE:  TOKEN. TPN 


FUNCTIONS  NEMTOt  .TO* 

pq:  :  i  ele  values:  TotEM-ii' 

PAF'ANETEP: :  none 

EFFECT  s  none 
INITIAL  VALUE !  na 

I'ESCFIPTlONs  Callei  td  create  ft  new  td>eh  structure  an® 

RETURN  The  INTEPNAL-IX'. 


FUNCTIONS  FAC . TO*  -TDt  • 

POSSIBLE  VALUES*  TQk  EH  F  UNC  T I  DNftL  ATTRIBUTE  EETS 
PAPAMETEF'  s  token—  i  i'  TD> 

EFFECTS  none 

INITIAL  VALUES  null  set 

I'E  CCF1  FT  I ONS  Retlwn?  the  token  functional  attpijijte  set  i’FAC  • 


FUNCTION:  TVFE.TOt  .'TO*  > 

POSSIBLE  VALUECs  token  t.fee 
F’AFAMETEFCs  token- t r  T0» 

EFFECTS  none 
INITIAL  VALUES  none 

BE SC PI FT I ON:  6i!'En  a  token- i t"  return  the  tokentvfe 
Note  that  no  action?  or  effect?  result  frdm 

THE  TO*  HOE'ULE  *  IT  MERELY  CREATES  AMI'  HOLI'S  AN®  REFORTS  ATTRIIUTES 
OF  TOKENS. 


FUNCTIONS 

POSS  IBLE  VALUES  s 


Chapter  VI 

A  TEPN  Model  of  a  Disk  Input/Output  Subsystem 


This  chapter  describes  the  application  of  the  TEPN  in 
modeling  the  performance  of  a  complex  disk  input/output  subsystem. 

Though  this  particular  problem  nay,  at  first  blush,  appear  as  a 
trivial  problem  not  significant  in  demonstrating  the  TEFN's  potential 
for  more  general  application,  careful  analysis  shows  that  this  case 
study,  which  was  motivated  by  a  real  rather  than  hypothetical 
problem,  requires  a  modeling  methodology  which  meets  the  goals 
indicated  in  the  Introduction  to  this  Thesis.  In  particular,  the 
disk  input/output  system  described  below  underscores  the  need  for  a 
modeling  methodology  which  can  faithfully  represent  deterministic 
behavior,  process  blocking,  and  the  holding  of  multiple  resources 
by  a  process. 

In  describing  the  TEPN  application,  the  chapter  demonstrates 
the  TEW  to  be  both  useful  and  significant:  useful  in  that  it  has 
sufficient  modeling  power  to  model  many  complex  systems,  and  significant 
in  that  it  can  model  systems  which  cannot  be  faithfully  modeled  by  the 
queueing  network  model. 

The  chapter  is  organized  into  three  major  sections.  The 
first  describes  the  basic  disk  I/O  configuration  used  throughout 
the  chapter  and  the  modeling  problems  that  emanate  from  this  con¬ 
figuration.  The  second  section  shows  why  the  queueing  network  model 
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is  structurally  inadequate  for  modeling  the  exact  structure  of  the  disk 
subsystem  when  either  disk  sharing  or  parallel  path  allocations  are 
employed.  The  final  section  presents  TEW  models  of  the  serial  and 
parallel  implementations  of  the  disk  I/O  configuration  under  study. 
These  sections  demonstrate  that  TEFN  models  can  represent  both  the 
serial  and  the  parallel  cases. 

Description  of  the  Disk  Subsystem  Problem  to  Be  Modeled 
Subsystem  Configuration 

Figure  6-1  illustrates  the  configuration  of  a  small  disk 
subsystem  representative  of  the  type  of  disk  input /output  subsystem 


DISK  INPOT/OUTPUT  SUBSYSTEM 
FIGURE  6-1 
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configured  to  many  data  processing  systems.  Though  the  configuration 
illustrated  is  very  small,  it  is  nonetheless  representative  of  many 
larger  disk  subsystems  in  that  the  same  conceptual  difficulties  are 
encountered  in  modeling  the  smaller  configuration  as  are  encountered 

g 

in  modeling  the  larger  configuration. 

In  describing  this  subsystem  for  modeling  purposes,  it  is 
necessary  to  describe  both  the  physical  configuration  characteristics 
and  the  operational  characteristics.  The  physical  configuration 
characteristics  define  the  structure,  or,  by  analogy,  the  syntax  of 
the  system  to  be  modeled.  From  Figure  6-1,  we  can  note  the  fol lowing 
physical  attributes: 

(1)  the  channels  are  crossbarred  across  both  controllers, 
with  the  result  that  either  controller  may  be  accessed  by  either 
channel; 


(2)  each  controller  is  attached  to  a  finite  and  fixed 
subset  of  the  set  of  disk  units  and  is  part  of  a  unique  path  from 
either  of  the  channels  to  any  disk  units  not  shared  with  another 
controller; 


A  "conceptual"  difficulty  relates  only  to  modeling  power/capability. 
Wfe  believe  the  TEPN  is  theoretically  equipped  to  model  any  real  disk 
I/O  subsystem  configuration.  Vhether  a  very  large  system  can  be 
"physically"  modeled  depends  more  upon  the  limits  of  the  implementation 
of  the  model,  and  not  the  model  itself. 


.JL  i  i 


mm* 


(3)  some  disk  drives  may  be  shared  by  two  or  more  con¬ 


trollers  (in  this  case,  the  second  drive  is  shared)  with  the  result 
that  there  are  multiple  paths  to  each  shared  unit. 

Control ler /Disk  Path  Allocation  Algorithm 

In  addition  to  the  above  characteristics,  all  of  which 
deal  with  the  physical  configuration  of  the  disk  subsystem,  there 
is  another  iirportant,  though  diagrammatical ly  invisible  feature: 
the  control  ler /disk  unit  path  allocation  algorithm,  or  the  algorithm 
used  to  determine  how  to  al locate  and  deallocate  the  controllers  and 
disk  units  when  handling  input/output  requests. 

There  are  two  major  path  allocation  algorithms  in  use. 

The  first,  the  serial  algorithm,  allocates  an  entire  control ler /disk 
unit  path  to  a  transaction  frcm  the  time  the  request  is  approved  for 
servicing  until  the  transfer  is  complete.  In  this  case,  if  a  disk 
unit  has  to  perform  a  seek  operation  before  the  data  transfer  opera¬ 
tion  can  begin,  the  controller  will  initiate  the  seek  and  wait  for 
it  to  finish,  not  accepting  any  other  work  during  the  idle  period. 

The  parallel,  or  SEEK: READ /VRITE  overlap  algorithm,  on  the 
other  hand,  only  allocates  devices  vhen  they  are  specifically  re¬ 
quired  for  a  transfer  or  seek  function.  Once  the  controller  has 
initiated  the  seek  operation,  for  example,  the  controller  will  be 
available  to  service  other  transfer  requests  while  it  is  waiting  for 
the  disk  to  complete  its  seek  operation.  Wien  the  disk  seek  is 
completed,  the  controller  must  be  reallocated  to  complete  the 

« 
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path  required  for  the  actual  transfer  operation.  Finally,  when  the 
operation  is  complete,  both  units  will  be  returned  to  the  system 
for  allocation  to  other  incoming  and  pending  input/output  requests. 

Difficulties  Encountered  Vhen  Modeling  the  Disk  Subsystem  with  the 
Queueing  Network  Model 

The  limitations  of  the  queueing  network  model  were  discussed 
in  Chapter  II.  This  section  presents  some  of  these  limitations  as 
they  particularly  apply  to  the  modeling  of  the  disk  subsystem  problem 
discussed  in  this  chapter. 

Browne,  et  al  [Browne,  et  al,  1973]  describe  the  represent¬ 
ational  problems  inherent  to  modeling  a  complex  disk  subsystem  (i.e. , 
other  than  the  trivial  cases  of  single-controller,  single-disk  systems) 
in  which  disk  sharing  and/or  the  parallel  path  allocation  algorithm 
are  enplqyed.^  In  particular,  they  showed  that  the  queueing  network 
model  cannot  model  the  exact  system  interactions  and  that  when  these 
interactions  are  crucial  to  the  model  it  is  currently  necessary  to 
model  and  simulate  the  subsystem  using  a  discrete  simulation  language 
model.  Three  of  the  difficulties  which  they  cited  are  described 
below. 

g 

Browne,  et  al,  studied  performance  characteristics  of  a  large 
Control  Data  Corporation  (CDC)  system  which  included  disk  drives 
especially  equipped  with  the  overlap  algorithm. 


aaaaa— 


Process  Blocking.  There  are  two  types  of  blocking  which 
may  happen  with  a  system  such  as  the  one  above.  The  first  involves 
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simple  queueing  on  the  controllers,  called  primary  blocking.  In  this 
case,  both  of  the  controllers  cure  busy,  either  initiating  a  seek  or 
performing  a  data  transfer  operation.  In  either  case,  the  request 
will  be  queued  on  the  incoming  path,  and  will  have  no  effect  upon 
the  disk  units.  Secondary  blocking  nay  occur  when  a  controller 
initiates  a  seek  operation  in  a  disk  unit  and  goes  on  to  service 
another  request,  and  is  not  free  to  begin  a  transfer  when  the  seek 
is  completed,  and  no  alternate  paths  are  free.  Intuitively,  every 
time  that  the  overlap  feature  is  utilized  there  is  an  opportunity 
for  secondary  blocking  to  occur. 


Holding  of  Multiple  Resources.  During  its  life  cycle,  each 
disk  request  transaction  must  hold  each  of  three  resources:  a  chan¬ 
nel,  a  controller,  and  a  disk  drive.  Although  the  queueing  network 
model  cannot  directly  model  the  holding  of  multiple  resources  if  the 
resources  are  always  deallocated  in  the  exact  reverse  order  of  their 
original  allocation,  a  queueing  network  model  can  be  designed  which 
will  faithfully  model  the  system  behavior.  Such  is  the  case  with  the 
serial  path  allocation  algorithm.  If  the  parallel  path  allocation 
algorithm  is  used,  however,  the  controller  and  channel  may  be  deal¬ 
located  and  then  reallocated  in  the  middle  of  a  transaction's  life 
cycle.  This  process  cannot  be  faithfully  modeled  with  a  queueing 
network  model. 
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Determinign  and  Multiple  Configurations.  The  need  for  a 
deterministic  model  versus  a  stochastic  representation  is  difficult 
to  see  in  seme  cases  in  vrfiich  the  workload  and  system  characteristics 
are  such  that  the  stochastic  model  closely  approximates  the  real 
system.  However,  when  either  fine-grain  accuracy  is  important, 
the  workload  characteristics  are  not  easily  "summarized"  into 
stochastic  functions,  or  the  configuration  may  change,  a  dis¬ 
crete,  deterministic  methodology  is  clearly  more  desirable  and 
sometimes  essential.  When  fine-grain  accuracy  is  important,  the 
deterministic  model  allows  the  analyst  to  model  exact  hardware 
characteristics,  rather  than  average  service  times.  This  may 
be  particularly  useful,  for  example,  for  studying  different  disk 
storage  strategies  (such  as  only  using  a  certain  block  of  tracks 
on  each  disk  drive).  Che  particular  advantage  of  a  determin¬ 
istic  model  is  that  it  may  more  easily  be  trace-driven,  thus 
reducing  the  need  to  preanalyze  and  characterize  the  input  work¬ 
load.  Finally,  when  studying  a  variety  of  configurations,  it  is 
sometimes  important  to  have  a  model  which  would  exactly  quantify 
the  impact  of  secondary  effects  (such  as  the  increase  or  decrease 
in  secondary  blocking)  before  the  effects  are  understood  enough 
to  characterize  them  stochastically. 

TEPN  Model  of  the  Disk  Subsystem  with  Serial  Path  Allocation 

The  description  of  the  TEW  model  of  the  disk  subsystem 
with  serial  path  allocation  is  divided  into  three  sections.  The 
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first  section  deals  with  the  model  structure  and  configuration. 

The  second  section  builds  upon  that  structure  by  defining  the  TEPN 
model  parameters  which  are  characteristic  of  this  particular  model. 

The  final  section  concerned  with  the  TEFN  model  of  the  disk  subsystem 
is  a  brief  discussion  of  the  model's  operational  characteristics. 

Once  a  model  has  been  defined  for  the  serial  path 
allocation  case,  only  a  few  modifications  are  required  to  convert 
the  model  to  represent  the  same  disk  subsystem  with  parallel  path 
allocation.  These  modifications  and  the  final  model  are  presented 
in  the  chapter's  final  section. 

Disk  Subsystem  Structure  and  Organization 

The  TEEN  model  structure  for  the  disk  subsystem  was  designed 
in  three  stages.  The  first  stage  was  to  decompose  the  two-controller, 
three-disk  subsystem  into  three  separate  disk  subsystems,  each  of  which 
contains  the  data  paths  possible  for  transferring  data  to  and  frcm 
one  of  the  three  disk  drives.  This  system  decomposition  is  diagram¬ 
matical  ly  illustrated  in  Figure  6-2.  Fran  Figure  6-2  we  can  see  that 
the  two  controller  three-drive  disk  subsystem  can  be  modeled  as  a 
combination  of  two  single- controller,  single-disk  subsystems  combined 
with  one  dual -controller,  single-drive  subsystem.  Figures  6-3  and  6-4 
illustrate  marked  TEEN  model  structures  which  could  effectively  rep¬ 
resent  these  two  basic  configurations.  The  reader  should  note  that 
the  structure  shown  in  Figure  6-4  is  essentially  identical  to  that 
shewn  in  Figure  6-3,  with  the  exception  that  a  controller  may  be 
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drawn  frcm  one  of  two  nodes  named  CNTAVL  instead  of  the  single 
CNTAVL  node  shewn  in  Figure  6-3.  The  addition  of  the  CT7IBSY  places 
insures  that  the  token  is  returned  to  one  of  two  CNTAVL  nodes  after 
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the  data  transfer  has  been  ccmpleted.  Table  6-1  presents  the  inter¬ 
pretation  of  each  of  the  places  labeled  in  Figure  6-3,  Figure  6-4, 
and  other  figures  throughout  Chapter  VI;  Table  6-2  presents  similar 
information  for  each  of  the  transitions. 

In  order  to  model  the  entire  two-controller,  three-disk 
system,  we  can  combine  the  models  of  the  separate  parts  of  the 
subsystem  into  a  single  large  model.  This  model  is  shewn  in 
Figure  6-5.  It  is  important  to  realize  that  this  illustration  only 
shows  the  structure  of  the  model.  From  this  structure  we  can 
determine  only  what  "states"  are  possible  ("reachable")  or  other 
analysis  possible  with  a  normal  Petri  net  (since  in  the  default 
case  the  TEFN  is  equivalent  to  a  Petri  net).  It  is  not  possible, 
however,  to  examine  the  model's  time-resolved  performance  without 
introducing  TEIN  semantic  (as  opposed  to  structured  or  syntactic) 
attributes. 

Although  the  model  in  Figure  6-5  represents  the  disk 
subsystem,  one  can  quickly  observe  that  a  model  built  in  this  manner 
would  rapidly  become  very  large  and  very  cumbersome  for  adl  but  the 
simplest  disk  subsystems.  Therefore,  it  is  necessary  to  be  able  to 
reduce  or  "collapse"  this  large  structure  into  a  simpler  but 
equivalent  structure.  An  appropriate  reduction  method  has  been 
suggested  by  both  Petri  net  researchers  and  the  TEFN  definition. 
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PLACE  NAME 

PLACE  INTER PRETATION/DESCRIPTION 

DSKREQ 

A  token  at  this  place  indicates  that  request  for  a  data 
transfer  is  waiting  in  the  system. 

CNTWr 

A  token  at  this  place  indicates  that  the  model  or  the 
subsystem  being  modeled  is  in  a  wait  state  waiting  for 
a  controller  to  become  available. 

CNTAVL 

The  tokens  at  this  place  indicate  the  availability  of 
a  controller  in  the  system.  In  the  cases  of  the  models 
in  Figures  6-3  and  6-4  these  places  are  bounded  to  a 
maximum  of  one  token.  That  token  then  becomes  repre¬ 
sentative  of  the  exact  controller  for  which  the  place 
is  designated. 

DSKWT 

Vhen  there  is  both  a  token  at  place  CNTWT  and  CNTAVL, 
transition  Tl  will  fire  and  transfer  a  token  to  place 

DSKWT.  This  place  indicates  that  the  model  is  in  a 
wait  state  for  an  available  disk  drive.  In  the  case 
of  these  models,  of  course,  this  disk  drive  is  exactly 
specified  to  be  either  disk  number  one,  number  two  or 
number  three. 

DSKAVL 

Tokens  residing  in  this  place  indicate  that  a  disk 
drive  is  available  for  matching  with  the  token  at 

DSKWT  or  in  terns  of  the  actual  system  being  modeled, 
a  disk  drive  is  available  for  matching  with  the 
appropriate  disk  request. 

DSKSEK 

Disk  seek  time  is  composed  of  both  track  seek  time 
and  rotational  delay. 

DESCRIPTIONS  OF  PLACES  WITHIN 
TEPN  MODEL  OF  DISK  I/O  SUBSYSTEM 


TABLE  6-1 
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PLACE  NAME  PLACE  INTERPRETATION/DESCRIPTION 


XFER 


XFERCP 


*XFERWT 


CHNAVL 

CNTRTN 


The  token  at  this  place  indicates  that  a  data  transfer 
is  under  way  and  therefore  that  the  disk/controller 
path  is  in  active  state. 

A  token  at  this  place  indicates  that  the  transfer  is 
complete.  Note  that  the  same  transition  that  sends  a 
token  to  this  place  also  sends  a  token  to  both  CNTAVL 
and  DSKAVL,  thus  "deallocating"  both  the  controller 
and  the  disk  that  was  in  use  during  the  transfer 
operation. 

For  each  request  being  processed  by  the  disk  subsystem, 
there  is  a  token  resident  at  this  place.  Vhen  the  transfer 
is  completed,  the  associated  token  is  released  with  the 
result  that  the  local  wait  time  of  the  XFERWT  token  js 
exactly  equal  to  the  combined  total  wait  times  for  all 
aspects  of  handling  the  request. 

A  token  at  this  place  indicates  channel  availability. 

This  place  is  only  included  in  the  model  illustrated 
in  Figure  6-4  and  is  required  in  order  to  allow  a 
token  to  return  to  either  one  of  the  CNTAVL  places. 

In  terms  of  the  actual  system,  this  would  allow  the 
controller  to  be  deallocated  to  the  proper  place. 

If  controller  A,  for  exanple,  had  been  allocated  as 
part  of  the  original  transfer  path,  then  the  token 
at  CNTRTN  would  travel  through  to  the  transition 
which  has  as  its  output  place  the  CNTAVL  associated 
with  controller  A;  and,  similarly,  if  controller  B 
had  been  part  of  the  allocated  path,  at  deallocation 
time  the  CNTAVL  place  associated  with  controller  B 
would  receive  the  token. 


**CNTBSY  The  two  places  with  this  name  (CNTBSYA  and  CNTBSYB) 
match  with  place  CNTRTN  to  insure  that  the  token  in 
CNTRTN  fires  the  correct  CNTAVL  place. 


*Not  included  in  Figures  6-3,  6-4,  and  6-5  but  included  in  the 
final  models  of  the  disk  subsystem. 

**Only  included  in  Figures  6-4  and  6-5. 

DESCRIPTIONS  OF  PLACES  WITHIN 
TEPN  MODEL  OF  DISK  I/O  SUBSYSTEM 


TABLE  6-1  (Cont'd) 
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TRANSITION 

INTERPRETATION  OF  FIRING 

T1 

[Any]  Channel  allocated  to  queued  disk  request; 
transaction  processing  cycle  begins. 

T2 

[Specified]  Controller  allocated  to  queued  disk 
request  transaction;  disk  request  queued  on 
[specified]  disk. 

T3 

[Specified]  Disk  allocated  to  queued  disk  request 
transaction;  disk  seek  activated;  channel 
deallocated  pending  completion  of  disk  seek 
operation . 

T4 

[Any]  Channel  allocated  for  disk  I/O  operation; 
disk  I/O  operation  initiated. 

T5 

End  of  disk  request  transaction  life  cycle; 
channel,  controller,  and  disk  unit 
deallocated. 

*T6 

[Specified]  Controller  returned  to  available 
("idle")  state. 

*only  included  in  Figures  6-4  and  6-5. 


DESCRIPTIONS  OF  TRANSITIONS 
TEPN  MODEL  OF  DISK  I/O  SUBSYSTEM 


TABLE  6-2 
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Within  the  Petri  net,  the  reduction  is  based  upon  properties  of 
token  types  or  colors.  Research  concerning  colored  petri  nets 
was  mentioned  earlier  in  this  Thesis  (see  footnote  6,  page  43). 

With  the  TEW,  this  reduction  capability  exists  in  the  form  of 
transition  firing  templates  and  the  companion  token  types  and 
token  templates.  Using  the  firing  template  concept,  the  model 
of  Figure  6-5  can  be  collapsed  into  a  compact  model  which  can 
represent  a  disk  subsystem  of  virtually  arbitrary  size  and  config¬ 
uration  complexity.  The  parameters  necessary  to  form  this  reduction 
are  presented  in  the  next  section. 

TEPN  Disk  Subsystem  (Serial  Path  Allocation)  Model  Parameters 

This  section  presents  the  TEW  model  parameters  which 
are  required  to  model  the  performance  of  the  disk  subsystem 
presented  in  Figure  6-1  of  this  chapter.  These  parameters  define 
not  only  the  characteristics  of  the  controller  disk  interactions  but 
are  also  used  to  define  the  actual  configuration  of  the  disk  sub¬ 
system.  The  place  attributes  are  primarily  concerned,  of  course, 
with  time  resolution,  and  therefore  embody  the  attributes  which 
inpact  such  things  as  disk  seek  time  and  data  transfer  times.  These 
attributes  are  the  same  regardless  of  the  number  of  disk  units  or 
controllers  within  the  subsystem.  They  are  also  insensitive  to  the 


Ill 


configuration  of  these  disks  or  controllers.  The  transition  firing 
templates  are  used  in  conjunction  with  the  token  types  to  define 
the  configuration  of  the  disk  subsystem.  In  particular,  the  tran¬ 
sition  firing  templates  cure  used  to  insure  that  only  legal  controller 
disk  paths  are  allocated.  Without  the  firing  template,  for  example, 
any  controller  token  could  be  matched  with  any  disk  token  to  enable 
a  transition  which  would  eventually  result  in  a  data  transfer. 

While  this  might  be  acceptable  in  some  systems,  it  is  not  acceptable 
in  a  trace-driven  modeling  environment  where  the  specific  disk  units 
are  paired  with  disk  reguests  and  the  performance  of  individual  disk 
drives  and  controllers  is  of  concern  to  the  analyst. 

Transition  Firing  Template.  The  Transition  Firing  Template 
determines  the  configuration  of  the  disk  subsystem  by  controlling 
which  controller  tokens  will  match  with  which  disk  or  disk  specific 
tokens  while  the  net  is  in  operation.  Within  the  model  of  Figure  6-5, 
the  major  reason  for  firing  templates  is  to  allow  a  method  of  matching 
disk  requests  with  the  appropriate  disk  drive  or  unit  and  matching 
disk  units  with  controllers  that  can  service  them.  For  exanple,  if 
a  disk  request  arrives  for  a  transfer  of  data  that  is  residing  on,  in 
the  real  system,  disk  unit  number  two,  we  know  that  that  disk  unit 
can  be  accessed  through  either  controller  A  or  controller  B.  However, 
if  another  disk  request  arrives  that  must  access  disk  unit  nunber  one, 
this  disk  unit  must  only  be  paired  with  controller  A.  In  Figure  6-5, 
this  problem  is  handled  by  having  a  separate  model  for  each  possible 
control ler/disk  combination.  However,  as  mentioned  before,  such  an 
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approach  would  require  a  very  cumbersome  network  in  even  a  snail 
subsystem.  A  firing  template  that  requires  that  the  input  token 
fran  Q7TAVL  match  a  certain  type  token  from  CNTWT,  however,  can  be 
used  to  guarantee  that  only  the  appropriate  controller  is  matched 
with  the  disk  request.  It  is  thus  possible  to  "collapse"  all  of 
the  models  for  various  control ler/disk  paths  into  a  single  model. 
Therefore,  the  first  firing  template  to  be  described  describes 
the  match  between  controllers  requests  and  disk  units.  Table  6-3 
describes  the  firing  templates  required  to  model  the  actual  con¬ 
figuration  shewn  in  Figure  6-1,  with  serial  path  allocation; 

Figure  6-6  shows  the  new  model  structure  that  results  when  these 
firing  templates  have  been  implemented.  Finally,  Table  6-4  presents 
the  formal  model  structure  definition  (in  terms  of  Definition  4.1) 
of  the  structure  in  Figure  6-6. 

Place  Attributes.  The  place  attributes  are  divided  into 
three  main  groups:  the  attributes  of  the  clock,  the  attributes 
of  the  Place  Active  Queue  (PAQ),  the  attributes  of  the  Place 
Enabled  Queue  (PEQ),  and  the  set  of  Place  J Performance  Functions 
(PPF) .  Table  6-5  lists  the  values  of  each  of  these  attribute  groups 
as  required  for  modeling  the  disk  subsystem  with  serial  path  allo¬ 
cation.  Since  each  of  the  attributes  were  ©plained  in  Chapter  IV, 
the  table  is  presented  with  little  additional  explanation,  beyond 
the  keys  located  at  the  bottom  of  the  chart  which  define  parameters 
used.  The  functions  used  to  define  the  TDIM  place  attributes  jure 
explained  in  Table  6-6. 
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1  (Tl) 

I  (T2) 

1  (T3)  - 
I  (T4)  ■ 
I  (T5)  * 


DSKIONET  -  (P,  T,  I,  0) 

where, 

P  -  (CHNAVL,  DSKREQ,  CNTWT,  CNTAVL,  DSKWT,  DSKAVL, 
DSKSEK,  XFER,  XFERCP ,  XFERWT} 

T  »  (Tl,  T2,  T3,  T4,  T5} 


{DSKREQ,  CHNAVL} 

0 

(Tl)  - 

(CNTWT,  XFERWT} 

(CNTWT,  CNTAVL} 

0 

(T2)  - 

(DSKWT}} 

(DSKWT,  DSKAVL,  CNTAVL} 

0 

(T3)  « 

(DSKSEK,  CHNAVL} 

(DSKSEK,  CHNAVL} 

0 

(T4)  * 

(XFER} 

(XFER,  XFERWT} 

0 

(T5)  = 

(CNTAVL,  DSKAVL,  XFERCP, 

CHNAVL} 


TEFN  Model  Structural  Definition 
Disk  I/O  Subsystem  with  Serial  Path  Allocation 


Table  6-4 
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Token  Attributes  and  Transition  Token  Templates.  Token 
attributes  and,  consequently,  token  templates  are  defined  by  the 
specifications  of  the  TEFN  place  and  transition  firing  template 
attributes.  More  specifically,  the  token  functional  attribute  set 
is  derived  primarly  from  the  set  of  functions  necessary  for  computation 
of  the  token  delay  time  mapping  (TDIM)  value  for  each  place.  These 
functions  can  be  identified  in  Tables  6-5  and  6-6  while  the  token  type 
attribute  is  derived  from  the  definition  of  the  transition  firing 
templates,  defined  in  Table  6-3.  In  addition  to  the  token  type  and 
functional  attributes  required  of  a  token  at  its  resident  place, 
many  tokens  cure  defined  to  carry  additional  attributes  which  are 
required  by  other  places  later  in  the  network.  These  attributes, 
which  are  defined  as  members  of  the  token  functional  attribute  set, 
could  be  viewed  as  "messages"  in  the  process  of  being  relayed 
from  thrir  source  to  their  destination.  An  example  of  this  is  the 
attribute  "SIZ"  which  (from  Table  6-5)  is  required  to  compute  the 
data  transfer  time  for  each  request,  shich  is  the  TDTM  value  for  a 
token  residing  at  place  XFER.  The  original  source  of  this  attribute 
is  the  token  fran  place  DSKKEJQ,  where  each  disk  request  is  initi¬ 
ated.  In  order  to  insure  that  this  piece  of  information  is  available 
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FUNCTION 

MNEMONIC 

.J  DESCRIPTION 

Request  Inter- 
Arrival  Tune 

INTARR 

Returns  the  amount  of  time 
prior  bo  releasing  the  next 
token  from  place  DSKREQ 

Request  Number 

REQNUM 

Returns  unique  identifier 
assigned  to  each,  new  disk 
request  transaction. 

Data  Transfer  Size 

SIZ 

Returns  number  of  units  of 
data  to  be  transferred  to 
this  transaction. 

Data  Track  Address 

TRK 

Returns  the  disk  unit  track 
address  of  the  data  to  be 
transferred. 

Disk  Position 

PCS 

Returns  the  current  track 
address  of  the  disk  unit 
read/write  head. 

Disk  Seek  Time 

SEKTIM 

Returns  the  disk  track- to- 
track  seek  time. 

TOKEN  FUNCTIONAL  ATTRIBUTES 
DISK  MODEL  OF  DISK  I/O  SUBSYSTEM 

TABLE  6-6 
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The  token  definitions  required  to  represent  the  disk  I/O 
subsystem  are  presented  in  Table  6-7.  Note  that  several  of  these 
definitions  show  tokens  with  "canposite"  token  types.  These  types 
are  actually  the  concatenation  of  several  types  and  are  used  to 
preserve  the  identity  of  the  resources  allocated  to  each  transaction 
as  the  model  is  executed.  The  notation  used  in  this  table,  while 
new,  is  intended  to  be  somewhat  self-explanatory.  All  definitions 
employed  standard  set  natation .  In  the  case  of  composite  token 
types,  lists  enclosed  in  square  brackets  are  single  type  elements. 
Also,  when  cne  of  the  elements  of  the  domain  set  is  itself  a 
set,  the  implication  is  that  any  of  the  "inner"  set  may  be  matched 
with  any  other  elements  in  the  composite  type  to  form  a  "legal" 
ordered  re-tuple. 

The  final  information  required  to  define  the  tokens  is  the 
transition  output  token  templates.  These  are  implied  by  the 
definitions  of  Tables  6-6  and  6-7  and  are  formally  presented  in 
Table  6-8.  For  brevity,  the  table  utilizes  a  functional  notation 
to  indicate  transfer  of  type  and  attribute  information.  The 
notation  should  be  clear  with  the  possible  exception  of  the 
notation  TYPE  *  TYn  (P),  where  n  is  a  digit  and  P  is  a  place 
name.  This  indicates  the  particular  element  of  the  ordered 
n- tuple  which  forms  a  canposite  type  of  a  token  frcm  place  P. 

The  particular  type  value  referred  to  can  be  determined  fran 
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TEPN  Model  of  the  Disk  I/O  Subsystem  with  Parallel  Path  Allocation 

In  order  to  effectively  model  parallel  path  al location, 
the  model  of  Figure  6-7  must  be  altered  to  allow  for  a)  the  return 
of  the  controller  to  the  available  state  for  the  CNTAVL  place 
during  the  time  period  taken  by  a  disk  seek  operation;  and,  b)  the 
reallocation  of  a  controller  from  OJTAVL  prior  to  the  commencement 
of  the  transfer  operation  but  following  the  completion  of  the  disk 
seek  operation.  The  exact  implementation  of  this  required  modification 
to  the  original  model  depends  upon  the  level  of  detail  required  for 
the  study.  In  most  cases,  for  example,  parail lei  path  allocation  could 
be  accurately  modeled  with  the  simplifying  assumptions  that 
(1)  the  controller  is  automatically  deallocated  at  the  beginning 
of  every  disk  seek  operation,  and,  (2)  once  the  disk 
seek  operation  is  complete,  the  transfer  will  begin  as  soon  as  the 
controller  token  is  available.  Assumption  1  does  not  take  into 
account  the  case  in  which  there  is  no  disk  seek  time.  In  this  case, 
the  algorithm  would  probably  be  defined  such  that  the  controller  would 
not  be  deallocated  and  the  transfer  operation  would  be  allowed  to 
begin  immediately.  This  assumption,  however,  is  not  considered 
significant  except  in  cases  where  very  minute  detail  of  modeling 
is  necessary,  since  this  assumption  would  be  expected  to  have  little 
inpact  upon  the  system  performance.  Furthermore,  in  the  case  where 
the  disk  seek  is  indeed  zero,  one  could  assume  that  transition  T-4 
would  immediately  fire,  thus  causing  the  immediate  reallocation  of 
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the  lost  controller.  The  second  assumption  is  certainly  the  more 
significant  of  the  two  assumptions  in  that  it  ignores  the  extra 
latency  or  rotational  delay  time  caused  when  a  controller  is  not 
immediately  available  to  service  a  disk  drive  that  lias  just  completed 
a  seek  operation."^  Therefore,  in  a  system  which  is  extremely  busy, 
in  terms  of  request  volume,  and  which  has  many  disk  units  attached 
to  the  same  controller,  this  assumption  could  result  in  inaccuracy 
of  the  results.  In  cases  where  the  above  assumptions  are  considered 
unacceptable,  a  model  may  be  further  modified  to  represent  the 
interactions  at  even  the  most  detailed  level.  The  more  complex  model 
is  not  included  in  this  Thesis  as  it  is  not  required  to  illustrate 
any  special  capabilities  of  the  TEFN  model. 

Differences  Between  the  Serial  and  Parallel  Model 

If  the  two  assumptions  mentioned  in  the  last  section  are 
made,  only  one  strucural  modification  is  required  to  convert  the  model 
into  an  accurate  representation  of  the  disk  subsystem  with  parallel 
allocation.  This  modification  is  to  add  an  output  arc  from  transition 
T1  to  places  CNTAVL  and  a  corresponding  input  arc  to  transition  T4  fran 
place  CNTAVL. 

"^Addition  of  an  automatic  "average  latency  time"  to  the  TDTM 
computed  transfer  time  would  only  partially  solve  this  problem 
since  it  would  be  based  upon  an  assumption  of  a  known  pattern  of 
latency  delays  which  may  not  be  the  case. 
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Bus  modification  cause  the  controller  to  be  returned  to  the 
CNTAVL  pool  until  it  is  required  by  another  (or  the  same,  at  later 
time)  transaction.  The  new  marked  structure  is  illustrated  in  figure 
6-7,  The  TERM  "structure  definition"  is  also  presented,  in  table  6-9. 
This  structural  change  requires  a  slight  redefinition  of  the  transition 
firing  and  token  templates.  The  no*  definitions  are  shown  in  tables 
6-10  and  6-11. 


Execution  of  the  Disk  Subsystem  Model 

Figures  6-8  thorugh  6-13  illustrates  an  execution  sequence  of 
the  model  of  figure  6-7  in  Which  a  disk  request  is  traced  through 
its  "life  cycle"  within  the  network.  Although  the  diagrams  are 
scmwhat  self-explanatory,  additional  notes  are  included  to  help  the 
reader  follow  the  example.  For  best  understanding,  it  is  suggeted 
that  the  tables  prensented  earlier  for  the  parallel  path  allocation 
disk  subsystem  model  be  followed  closely  through  the  execution 
cycle.  Table  6-12  presents  initial  valves  for  each  of  the  token 
functions  to  be  used  in  TDIW  canputations.  The  cycle  is  broken 
down  into  six  steps,  as  follows: 

1.  New  Request  Arrives  (fig  6-8)  at  place  DSKREQ,  specifying 
the  dirve  required  (DSKNLM) ,  (which  is  the  token's  type  attribute) 
data  track  address  (TRK),  the  amounnt  of  data  (SI2),  and  a  request 
nunber  (REOTOMB).  Example  attributes  are  shewn  in  table  6-12. 


DSKIONET  =  (P,  T,  I,  0) 


where, 

P  =  {CHNAVL,  DSKREQ,  CNTWT,  CNTAVL,  DSKWT,  DSKAVL, 
DSKSEK,  XFER,  XFERCP,  XFERWT} 

T  =  {Tl,  T2 ,  T3 ,  T4,  T5> 


I 

(Tl)  = 

{DSKREQ,  CHNAVL} 

0 

(Tl)  = 

{CNTWT,  XFERWT) 

I 

(T2)  * 

{ CNTWT ,  CNTAVL) 

0 

(T2)  = 

{DSKWT} 

I 

(T3)  = 

{DSKWT,  DSKAVL} 

0 

(T3)  = 

{DSKSEK,  CNTAVL,  CHNAVL} 

I 

(T4)  * 

{DSKSEK,  CHNALL} 

0 

(T4)  * 

{XFER} 

I 

(T5)  = 

{XFER,  XFERWT} 

0 

(T5)  = 

{CNTAVL,  DSKAVL,  XFERCP, 

CHNAVL} 


TEFN  Model  Structural  Definition 
Disk  I/O  Subsystem  with  Parallel  Path  Allocation 

Table  6-9 
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2.  Channel  Allocation  (fig  6-9)  of  a  channel  to  the  request. 

3.  Controller  Allocation  (fig  6-10)  of  controller  "A"  from 
place  CNTAVL.  Because  of  the  token  template  defined  for  transition 
T2,  only  controller  "A*  can  be  used  in  combination  with  DSKNIMB  "1" 
to  enable  T2.  Note  that  the  type  of  the  output  token  from  T2  to 
ONKWT  is  a  composite  type  indicating  the  enitre  channel -controller- 
disk  path  being  utilized. 

4.  Disk  Allocation  /  Release  of  Controller  (fig  6-11)  of  disk 
"1"  and  controller  "A*.  Because  the  parallel  path  algorithm,  the 
controller  is  not  retained  during  the  disk  seek  time. 

5.  Disk  Seek  (fig  6-12)  according  ot  the  pre-defined  TEOM  in  which 
WAIT  *  SEKTIME  *  abs(TRK-FOS) .  =lms  *(180-100)  =80ms,  using  values 
from  Table  6-12. 

6.  Transfer  Begins  (fig  6-12)  and  controller  and  channel  are 
both  reallocated  to  the  data  transfer  request.  The  transfer  time 
is  computed  according  to  the  TDIM  defined  for  place  XFER.  In  this 
case  the  wait  time  would  be;  SIZ  *  RATE  =  50)  block  *25  ms. 

7.  Transfer  Complete  (fig  6-13)  and  all  resources  deallocated.  Note 
merger  at  transition  T5  with  place  XFERWT.  This  place  is  oily  for 
recording  the  total  wait  time  fro  request  processing,  which  for 
this  example  would  be  total  of  the  wait  time,  or;  50  ms  +  80  ms* 
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MARKED  TEPN  MODEL  AFTER  TRANSITION  T2  FIRES 
INDICATING  ALLOCATION  OF  CONTROLLER  TO  DISK  REQUEST 


FIGURE  6-11 
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Further  analysis  of  the  model  and  experimentation  with  various 
initial  markings  will  quickly  reveal  the  versatility  and  the  struc¬ 
tural  integrity  of  this  model,  and  of  the  TEEN  model  in  general. 

Token  Generation.  The  fined,  question  that  will  be  discussed 
in  this  Thesis  concerning  the  example  TEEN  model  is  that  of  devi¬ 
sing  a  method  for  continuous  "generation"  of  input  tokens,  such  as 
the  tokens  which  would  ccrne  to  the  DSKREQ  place  in  order  to  evaluate 
the  subsystem  performance.  While  an  in-depth  discussion  of  this  topic 
is  not  appropriate  at  this  point,  a  brief  presentation  of  some  of 
the  natural  alternatives  offered  by  the  TEFN  is  again  illustrative 
of  the  potential  that  the  methodology  has  for  CPE  modeling. 

In  particular,  we  identify  three  ways  that  the  TEEN  can  handle  this 
need: 

1.  Closed  Network 

By  drawing  an  arc  from  transition  T5  to  place  DSKREQ,  figure 
6-6  can  be  transformed  into  a  closed  system  which  will  continue  to 
"recycle"  its  "workload"  indefinitely.  In  this  case,  the  parameters 
of  DSKREQ  tokens  could  be  either  drawn  frcm  a  random  field  or  kept 
constant  (to  represent,  for  example,  known  "typical"  requests).  Figure 
6-14  illustrates  the  resulting  structure. 

2.  Open  Network/Randcmly  Driven 

Figure  6-15  illustrates  a  second  implementation  method  in  which 
a  special  "token  generator"  place  has  been  added.  The  net  would  be 
initialized  by  inserting  a  token  at  place  TOKGEN.  After  some  deter- 
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mined  delay  time,  transition  T  would  fire,  sending  a  token  to  D6KREQ 
and  returning  a  token  to  TOKGEN.  The  token  template  could  be  designed 
to  either  retain  standard  parameters  or  to  chose  new  parameters 
either  randomly  or  from  a  separate  source. 

3.  Open  Network/Trace  Driven 

The  model  of  Figure  6-8,  finally,  could  be  used  as  a  trace  dri¬ 
ven  model  by  simply  defining  the  token  template  processor  such  that 
a  "READ  ATTRIBUTE"  operation  used  to  obtain  an  attribute  value  for 
inclusion  in  a  new  token  could  be  an  input  from  any  source,  inclu¬ 
ding  a  file  of  actual  system  transactions.  Note  that  this  imple¬ 
mentation  does  not  require  ary  modification  to  either  the  TEEN 
Definition  or  to  the  implementation  specifications.  This  implemen¬ 


tation  is  illustrated  in  Figure  6-16. 


CHAPTER  V I  I 


SUMMARY  AND  CONCLUSIONS 

The  primary  result  of  this  research  is  the  definition  of 
a  new  CPE  modeling  structure,  the  Time-Extended  Petri  Net,  which 
effectively  retains  logical  synchronization  and  concurrency 
characteristics  of  systems. 

Cost  effectiveness  is  an  important  consideration  when 
evaluating  the  potential  of  any  CPE  methodology.  A  further  result 
of  this  research,  therefore,  is  the  demonstration  of  the  feasibility 
to  (1)  develop  an  efficient  computerized  TEPN  modeling  system,  and 
(2)  use  the  TEPN  in  analyzing  practical  CPE  problems.  The  initial, 
though  limited  results  included  in  this  thesis  demonstrate  that  the 
TEPN  is  applicable  to  at  least  a  small  class  of  problems.  More 
research  and  testing  will  be  required  before  the  TEPN  can  be 
declared  to  be  a  general  CPE  tool;  this  research  is  underway  at 
this  time. 

At  this  point,  the  use  of  the  TEPN  as  a  modeling  tool 
for  many  problems  is  still  a  cumbersome  task.  There  is  still 
considerable  work  ahead  before  the  implementation  becomes  efficient 
and  sufficiently  user  oriented  to  allow  cost  effective  modeling  of 
large  system  evaluation  problems.  However,  the  results  of  this 
Thesis  seem  to  Indicate  the  potential  for  building  and  evaluating 
effective  models  of  such  systems  at  a  fraction  of  the  cost  of 
building  full-scale  simulation  models. 
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Appendix  A 

Decomposition  of  a  T£PN  Model  into  a  Petri  Net 
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One  of  the  stated  advantages  of  the  TEPN  structure  is 
that  it  has  the  flexibility  to  "decompose"  into  a  Petri  net  without 
any  alteration  of  the  basic  model  structure.  Therefore,  the  same 
model  could  be  used  to  study  many  theoretical  properties  (such  as 
state  reachability)  using  the  identical  model. 

Building  a  "default"  Petri  net  consists  of  steps: 

(1)  Define  all  places  within  the  net  with  the  standard 
default  parameters; 

(2)  Define  all  transition  firing  and  token 

TEPN  Place  Default  Parameters 

On  an  operational  level,  the  TEPN  and  Petri  net  place 
differ  primarily  in  that  (a)  "time"  is  resolved  within  the  place, 
and  (b)  the  TEPN  place  is  capable  of  ordering  its  resident  tokens 
and  using  this  ordering  to  control  the  exit  of  tokens  to  its 
output  transitions.  In  order  to  decompose  a  TEPN  place  so  that  it 
is  operationally  equivalent  to  the  standard  Petri  net  place,  there¬ 
fore,  one  must  define  all  attributes  such  that  the  above  two 
differences  are  eliminated.  Such  a  set  of  parameters  is  shown  in 
table  A- I . 

The  net  effect  of  the  default  attributes  is  to: 

(I)  remove  time  resolution  from  the  place  by  "deacti¬ 
vating"  the  clock  to  a  constant  zero  state. 
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(2)  remove  the  concept  of  "token  delay  time"  by  defining 
the  TDTM  as  a  constant  zero  function, 

(3)  define  the  place  marking  as  a  "bag"  or  set  of  tokens 
rather  than  a  queue  or  sequence  by  defining  a  queueing  discipline 
which  has  an  infinite  number  of  processors  resulting  in  elimination 
of  any  queueing  delays,  and, 

(4)  define  the  place  as  "dnbounded,"  in  accordance  with 
the  generalized  Petri  net  definition. 

If  all  places  in  the  structure  of  figure  6-6  were  defined 
with  default  attributes  and  if  transition  firing  templates  were  left 
undefined,  the  net  "performances"  would  completely  revert  to  a  Petri 
net  (although  the  internal  structure  would  still  be  a  TEPN,  as 
evidenced  by  the  retention  of  a  set  of  place  performance  functions. 

TEPN  Transition  Default  Parameters  Default  Transition  Firing  Templates 

The  Petri  net  transition  has  no  mechanism  for  controlling 
token  flow  other  than  the  standard  enabling  rules.  Therefore,  the 
TEPN  transition  default  parameters  must  be  defined  such  that  the 
enabling  and  firing  rules  conform  to  the  standard:  if  a  token  exists 
at  each  input  places,  regardless  of  the  tokens'  attributes.  Therefore, 
the  default  transition  parameter  set  includes  a  nut i  firing  template 
conforming  to  definition  A.1,  below. 


Definition  A-1.  Null  TEPN  Transition  Firing  Template 
A  TEPN  transition  firing  template  is  said  to  be  nu i I  if 
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the  transition  will  be  enabled  by  any  arbitrary  com¬ 
bination  of  input  tokens  as  long  as  there  is  at  least 
one  token  at  each  input  place.  In  functional  terms,  for 
any  transition  T, 

TFT (T)  =  "ENABLED"  if  LlMi^rO  for  every  Pi  in  I  (T) 
where,  LIMi  is  the  local  internal  marking  of  place  Pi. 

Default  TEPN  Token  and  Transition  Token  Template 

The  only  TEPN  token  attribute  which  is  supported  by  the 
Petri  net  is  the  token  type  ,  or  "color".  Therefore,  all  token 
templates  within  a  default  transition  are  restricted  to  defining  a 
simple  colored  token.  As  with  the  TEPN,  however,  there  is  still  con¬ 
siderable  flexibility  as  to  how  the  color  is  determined. 

The  default  TEPN  token  is  defined  by  definition  A-2.  Based 
upon  this  definition,  the  TEPN  Transition  Token  Template  will  only  be 
concerned  with  they  token  type  or  color. 

Definition  A-2.  Default  TEPN  Token 

The  default  TEPN  Token  is  a  TEPN  token  with  a  null  token 
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Attribute 


Va  I  ue 


Meaning/Remarks 


CLOCK 

INACTIVE 

Place  clock  is  a  constant 
zero 

PAQ  Queue 
Discipline 

IP 

"Infinite  Processor"  Queue 
d i sci p 1 i nes 

PAQ  Queue  Bound 

oo 

Infinite  Queue  Bound 

PAQ  TDTM 

D  =  F0(token) 

Constant  zero  delay  time 
function 

PEQ  Queue 

Discipl ine 

IP 

"Infinite  Processor" 
discipline 

PEQ  Queue  Bound 

C0 

Infinite  Queue  Bound 

Place  Performance 
Functions 

TPUT 

Total  number  of  tokens 
throughput 

QMAX 

The  largest  queue  size 
attained  during  run 

QSIZE 

Average  size  of  queue 
from  samp le 

Place  Attributes 
Tab 


of  "Default" 
e  A- 1 


Place 
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